GNU logs - #31067, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#31067: 27.0.50; After-string hidden by subsequent invisible text
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 05 Apr 2018 02:29:02 +0000
Resent-Message-ID: <handler.31067.B.15228953117809 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 31067 <at> debbugs.gnu.org
From: Stefan Monnier <monnier@HIDDEN>
Date: Wed, 04 Apr 2018 22:28:59 -0400
Message-ID: <jwvmuyi9yj8.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Package: Emacs
Version: 27.0.50


In a fresh Emacs session define:

    (defun foo ()
      (interactive)
      (with-current-buffer "*scratch*"
        (add-to-invisibility-spec '(foo . t))
        (let ((beg (point)))
          (insert "text")
          (let ((ol1 (make-overlay beg (point))))
            (overlay-put ol1 'after-string "!after!")
            (overlay-put ol1 'evaporate t)))
        (let ((beg (point)))
          (insert "\nhidden")
          (let ((ol1 (make-overlay beg (point))))
            (overlay-put ol1 'invisible 'foo)
            (overlay-put ol1 'evaporate t)))))

and then try it with `M-x foo`.
The result for me is to display "text...", whereas I would have expected
"text!after!...".

I.e. the after-string which I placed over "text" gets hidden by
`invisible` property of the overlay placed on the immediately following
"\nhidden".

I know these kinds of interactions are pretty delicate and often
somewhat arbitrary (several behaviors are valid and we just have to pick
one), but I think in this case it is clearly an error.


        Stefan

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Stefan Monnier <monnier@HIDDEN>
Subject: bug#31067: Acknowledgement (27.0.50; After-string hidden by
 subsequent invisible text)
Message-ID: <handler.31067.B.15228953117809.ack <at> debbugs.gnu.org>
References: <jwvmuyi9yj8.fsf@HIDDEN>
X-Gnu-PR-Message: ack 31067
X-Gnu-PR-Package: emacs
Reply-To: 31067 <at> debbugs.gnu.org
Date: Thu, 05 Apr 2018 02:29:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 31067 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
31067: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D31067
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#31067: 27.0.50; After-string hidden by subsequent invisible text
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 05 Apr 2018 09:50:02 +0000
Resent-Message-ID: <handler.31067.B31067.152292175915658 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Stefan Monnier <monnier@HIDDEN>
Cc: 31067 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Date: Thu, 05 Apr 2018 12:49:20 +0300
Message-Id: <8360562db3.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <jwvmuyi9yj8.fsf@HIDDEN> (message from Stefan Monnier
 on Wed, 04 Apr 2018 22:28:59 -0400)
References: <jwvmuyi9yj8.fsf@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> From: Stefan Monnier <monnier@HIDDEN>
> Date: Wed, 04 Apr 2018 22:28:59 -0400
> 
>     (defun foo ()
>       (interactive)
>       (with-current-buffer "*scratch*"
>         (add-to-invisibility-spec '(foo . t))
>         (let ((beg (point)))
>           (insert "text")
>           (let ((ol1 (make-overlay beg (point))))
>             (overlay-put ol1 'after-string "!after!")
>             (overlay-put ol1 'evaporate t)))
>         (let ((beg (point)))
>           (insert "\nhidden")
>           (let ((ol1 (make-overlay beg (point))))
>             (overlay-put ol1 'invisible 'foo)
>             (overlay-put ol1 'evaporate t)))))
> 
> and then try it with `M-x foo`.
> The result for me is to display "text...", whereas I would have expected
> "text!after!...".
> 
> I.e. the after-string which I placed over "text" gets hidden by
> `invisible` property of the overlay placed on the immediately following
> "\nhidden".
> 
> I know these kinds of interactions are pretty delicate and often
> somewhat arbitrary (several behaviors are valid and we just have to pick
> one), but I think in this case it is clearly an error.

Would you expect the after-string to be shown in the variant below?

(defun foo ()
  (interactive)
  (with-current-buffer "*scratch*"
    (add-to-invisibility-spec '(foo . t))
    (let ((beg (point))
	  end)
      (insert "hidden")
      (setq end (point))
      (insert "text")
      (let ((ol1 (make-overlay beg end)))
        (overlay-put ol1 'after-string "!after!")
        (overlay-put ol1 'evaporate t))
      (let ((ol2 (make-overlay (1+ beg) (point))))
        (overlay-put ol2 'invisible 'foo)
        (overlay-put ol2 'evaporate t)))))

IOW, the question is what should happen when the end-point of the
overlay with after-string is in invisible text?

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#31067: 27.0.50; After-string hidden by subsequent invisible text
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 05 Apr 2018 12:24:02 +0000
Resent-Message-ID: <handler.31067.B31067.15229310154622 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 31067 <at> debbugs.gnu.org
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvbmexn8u5.fsf-monnier+emacsbugs@HIDDEN>
References: <jwvmuyi9yj8.fsf@HIDDEN> <8360562db3.fsf@HIDDEN>
Date: Thu, 05 Apr 2018 08:23:30 -0400
In-Reply-To: <8360562db3.fsf@HIDDEN> (Eli Zaretskii's message of "Thu, 05 Apr
 2018 12:49:20 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> Would you expect the after-string to be shown in the variant below?
>
> (defun foo ()
>   (interactive)
>   (with-current-buffer "*scratch*"
>     (add-to-invisibility-spec '(foo . t))
>     (let ((beg (point))
> 	  end)
>       (insert "hidden")
>       (setq end (point))
>       (insert "text")
>       (let ((ol1 (make-overlay beg end)))
>         (overlay-put ol1 'after-string "!after!")
>         (overlay-put ol1 'evaporate t))
>       (let ((ol2 (make-overlay (1+ beg) (point))))
>         (overlay-put ol2 'invisible 'foo)
>         (overlay-put ol2 'evaporate t)))))
>
> IOW, the question is what should happen when the end-point of the
> overlay with after-string is in invisible text?

If some (or all) of the end of the overlay-with-after-string is made
invisible, then the situation is much less clear and I could see
arguments either way, but if I get to choose then I think it makes sense
to consider that the after string is "attached" to the end of the
overlay, i.e. if the end of the overlay is invisible then so is the
after-string.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31067: 27.0.50; After-string hidden by subsequent invisible text
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 05 Apr 2018 13:39:01 +0000
Resent-Message-ID: <handler.31067.B31067.152293548511168 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31067
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 31067 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 31067-submit <at> debbugs.gnu.org id=B31067.152293548511168
          (code B ref 31067); Thu, 05 Apr 2018 13:39:01 +0000
Received: (at 31067) by debbugs.gnu.org; 5 Apr 2018 13:38:05 +0000
Received: from localhost ([127.0.0.1]:39047 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f455Z-0002u4-Jo
	for submit <at> debbugs.gnu.org; Thu, 05 Apr 2018 09:38:05 -0400
Received: from eggs.gnu.org ([208.118.235.92]:45803)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1f455X-0002tY-Bw
 for 31067 <at> debbugs.gnu.org; Thu, 05 Apr 2018 09:38:03 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1f455M-0003T8-DM
 for 31067 <at> debbugs.gnu.org; Thu, 05 Apr 2018 09:37:56 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38807)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1f455M-0003T4-9a; Thu, 05 Apr 2018 09:37:52 -0400
Received: from [176.228.60.248] (port=3037 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1f455L-0001m1-OM; Thu, 05 Apr 2018 09:37:52 -0400
Date: Thu, 05 Apr 2018 16:38:05 +0300
Message-Id: <83zi2h22pu.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <jwvbmexn8u5.fsf-monnier+emacsbugs@HIDDEN> (message from Stefan
 Monnier on Thu, 05 Apr 2018 08:23:30 -0400)
References: <jwvmuyi9yj8.fsf@HIDDEN> <8360562db3.fsf@HIDDEN>
 <jwvbmexn8u5.fsf-monnier+emacsbugs@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: 31067 <at> debbugs.gnu.org
> Date: Thu, 05 Apr 2018 08:23:30 -0400
> 
> > IOW, the question is what should happen when the end-point of the
> > overlay with after-string is in invisible text?
> 
> If some (or all) of the end of the overlay-with-after-string is made
> invisible, then the situation is much less clear and I could see
> arguments either way, but if I get to choose then I think it makes sense
> to consider that the after string is "attached" to the end of the
> overlay, i.e. if the end of the overlay is invisible then so is the
> after-string.

But that's exactly what happens in your original example.

Btw, "some or all of the end" is a strange wording, because the end is
a (dimensionless) point.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31067: 27.0.50; After-string hidden by subsequent invisible text
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 05 Apr 2018 15:56:01 +0000
Resent-Message-ID: <handler.31067.B31067.152294374823925 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31067
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 31067 <at> debbugs.gnu.org
Received: via spool by 31067-submit <at> debbugs.gnu.org id=B31067.152294374823925
          (code B ref 31067); Thu, 05 Apr 2018 15:56:01 +0000
Received: (at 31067) by debbugs.gnu.org; 5 Apr 2018 15:55:48 +0000
Received: from localhost ([127.0.0.1]:39583 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f47Ep-0006Dp-Ub
	for submit <at> debbugs.gnu.org; Thu, 05 Apr 2018 11:55:48 -0400
Received: from pruche.dit.umontreal.ca ([132.204.246.22]:36761)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1f47Eo-0006Dg-0M
 for 31067 <at> debbugs.gnu.org; Thu, 05 Apr 2018 11:55:47 -0400
Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242])
 by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w35FtiFg028926;
 Thu, 5 Apr 2018 11:55:44 -0400
Received: by pastel.home (Postfix, from userid 20848)
 id E8D82604B9; Thu,  5 Apr 2018 11:55:43 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvk1tllkwg.fsf-monnier+emacsbugs@HIDDEN>
References: <jwvmuyi9yj8.fsf@HIDDEN> <8360562db3.fsf@HIDDEN>
 <jwvbmexn8u5.fsf-monnier+emacsbugs@HIDDEN> <83zi2h22pu.fsf@HIDDEN>
Date: Thu, 05 Apr 2018 11:55:43 -0400
In-Reply-To: <83zi2h22pu.fsf@HIDDEN> (Eli Zaretskii's message of "Thu, 05 Apr
 2018 16:38:05 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 5
X-NAI-Spam-Score: 0
X-NAI-Spam-Rules: 2 Rules triggered
	EDT_SA_DN_PASS=0, RV6258=0
X-NAI-Spam-Version: 2.3.0.9418 : core <6258> : inlines <6549> : streams
 <1783281> : uri <2620949>
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.3 (-)

>> > IOW, the question is what should happen when the end-point of the
>> > overlay with after-string is in invisible text?
>> If some (or all) of the end of the overlay-with-after-string is made
>> invisible, then the situation is much less clear and I could see
>> arguments either way, but if I get to choose then I think it makes sense
>> to consider that the after string is "attached" to the end of the
>> overlay, i.e. if the end of the overlay is invisible then so is the
>> after-string.
> But that's exactly what happens in your original example.

Hmmm.... not that I can see: the overlay covers "text" and none of it
is hidden.

I guess you could pay attention to the stickiness of the boundaries, but
in my example the end of the overlay-with-after-string is not sticky, so
you could say that it ends right after "t" and not on the immediately
following "(dimensionless) point".  Also I changed my test so that the
beginning of the invisible overlay is not sticky (so that the
"(dimensionless) point" between "t" and "\n" is supposedly not affected
by this overlay):

(defun foo ()
  (interactive)
  (with-current-buffer "*scratch*"
    (add-to-invisibility-spec '(foo . t))
    (let ((beg (point)))
      (insert "text")
      (let ((ol1 (make-overlay beg (point))))
        (overlay-put ol1 'after-string "!after!")
        (overlay-put ol1 'evaporate t)))
    (let ((beg (point)))
      (insert "\nhidden")
      (let ((ol1 (make-overlay beg (point) nil t)))
        (overlay-put ol1 'invisible 'foo)
        (overlay-put ol1 'evaporate t)))))

but the result is still the same.  And think this one is even more
clearly a bug, because according to stickiness the two overlays "don't
touch" (as can be tested by carefully moving point right after the "t" and
inserting "-" which gives you a display of "text!after!-" showing that
the "-" was inserted between the two overlays rather than into the
first or into the second or into both).

> Btw, "some or all of the end" is a strange wording,

Indeed, I added "or all" after the fact and did it poorly.  I meant "if
the last few chars covered by the overlay (or the whole text covered
by the overlay) is made invisible ...".


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31067: 27.0.50; After-string hidden by subsequent invisible text
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 05 Apr 2018 18:01:01 +0000
Resent-Message-ID: <handler.31067.B31067.15229512262360 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31067
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 31067 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 31067-submit <at> debbugs.gnu.org id=B31067.15229512262360
          (code B ref 31067); Thu, 05 Apr 2018 18:01:01 +0000
Received: (at 31067) by debbugs.gnu.org; 5 Apr 2018 18:00:26 +0000
Received: from localhost ([127.0.0.1]:39644 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f49BR-0000c0-Nn
	for submit <at> debbugs.gnu.org; Thu, 05 Apr 2018 14:00:25 -0400
Received: from eggs.gnu.org ([208.118.235.92]:51301)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1f49BQ-0000bm-L5
 for 31067 <at> debbugs.gnu.org; Thu, 05 Apr 2018 14:00:25 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1f49BH-0005KQ-Fs
 for 31067 <at> debbugs.gnu.org; Thu, 05 Apr 2018 14:00:19 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43993)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1f49BH-0005KM-Bn; Thu, 05 Apr 2018 14:00:15 -0400
Received: from [176.228.60.248] (port=3594 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1f49BG-0004me-PT; Thu, 05 Apr 2018 14:00:15 -0400
Date: Thu, 05 Apr 2018 21:00:28 +0300
Message-Id: <83tvsp1qkj.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <jwvk1tllkwg.fsf-monnier+emacsbugs@HIDDEN> (message from Stefan
 Monnier on Thu, 05 Apr 2018 11:55:43 -0400)
References: <jwvmuyi9yj8.fsf@HIDDEN> <8360562db3.fsf@HIDDEN>
 <jwvbmexn8u5.fsf-monnier+emacsbugs@HIDDEN> <83zi2h22pu.fsf@HIDDEN>
 <jwvk1tllkwg.fsf-monnier+emacsbugs@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: 31067 <at> debbugs.gnu.org
> Date: Thu, 05 Apr 2018 11:55:43 -0400
> 
> >> If some (or all) of the end of the overlay-with-after-string is made
> >> invisible, then the situation is much less clear and I could see
> >> arguments either way, but if I get to choose then I think it makes sense
> >> to consider that the after string is "attached" to the end of the
> >> overlay, i.e. if the end of the overlay is invisible then so is the
> >> after-string.
> > But that's exactly what happens in your original example.
> 
> Hmmm.... not that I can see: the overlay covers "text" and none of it
> is hidden.

The overlay's end point is _after_ "text", and that's exactly where
the invisible text starts.  And after-string _follows_ the end of
"text", so it starts where the invisible text starts.

> I guess you could pay attention to the stickiness of the boundaries

I don't think stickiness has anything to do with this.  I could
explain how the particular implementation of these features causes the
after-string to be skipped in this case, but I prefer that we first
establish the principles and the concepts.  From my POV, the
implementation does what it does because it considers after-string,
conceptually, to _follow_ the end-point of the overlay, and in this
case what follows it is invisible.

> And think this one is even more
> clearly a bug, because according to stickiness the two overlays "don't
> touch" (as can be tested by carefully moving point right after the "t" and
> inserting "-" which gives you a display of "text!after!-" showing that
> the "-" was inserted between the two overlays rather than into the
> first or into the second or into both).

They cannot "not touch", because there's nothing between 'after
"text"' and 'before the following point'.  The fact that inserting a
character behaves in some specific way doesn't matter, because the
display engine doesn't (and shouldn't) consider stickiness, it only
considers which display elements follow which.

> I meant "if the last few chars covered by the overlay (or the whole
> text covered by the overlay) is made invisible ...".

And that's what happens: the overlay's end-point is made invisible.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31067: 27.0.50; After-string hidden by subsequent invisible text
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 05 Apr 2018 19:16:02 +0000
Resent-Message-ID: <handler.31067.B31067.15229557348799 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31067
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 31067 <at> debbugs.gnu.org
Received: via spool by 31067-submit <at> debbugs.gnu.org id=B31067.15229557348799
          (code B ref 31067); Thu, 05 Apr 2018 19:16:02 +0000
Received: (at 31067) by debbugs.gnu.org; 5 Apr 2018 19:15:34 +0000
Received: from localhost ([127.0.0.1]:39675 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f4AM9-0002Hr-NH
	for submit <at> debbugs.gnu.org; Thu, 05 Apr 2018 15:15:33 -0400
Received: from chene.dit.umontreal.ca ([132.204.246.20]:53117)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1f4AM8-0002Hi-11
 for 31067 <at> debbugs.gnu.org; Thu, 05 Apr 2018 15:15:33 -0400
Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242])
 by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w35JFTqE009165;
 Thu, 5 Apr 2018 15:15:30 -0400
Received: by ceviche.home (Postfix, from userid 20848)
 id D10576637D; Thu,  5 Apr 2018 15:15:29 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwv4lkpjxf2.fsf-monnier+emacsbugs@HIDDEN>
References: <jwvmuyi9yj8.fsf@HIDDEN> <8360562db3.fsf@HIDDEN>
 <jwvbmexn8u5.fsf-monnier+emacsbugs@HIDDEN> <83zi2h22pu.fsf@HIDDEN>
 <jwvk1tllkwg.fsf-monnier+emacsbugs@HIDDEN> <83tvsp1qkj.fsf@HIDDEN>
Date: Thu, 05 Apr 2018 15:15:29 -0400
In-Reply-To: <83tvsp1qkj.fsf@HIDDEN> (Eli Zaretskii's message of "Thu, 05 Apr
 2018 21:00:28 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 5
X-NAI-Spam-Score: 0
X-NAI-Spam-Rules: 2 Rules triggered
	EDT_SA_DN_PASS=0, RV6258=0
X-NAI-Spam-Version: 2.3.0.9418 : core <6258> : inlines <6550> : streams
 <1783294> : uri <2621027>
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.3 (-)

>> >> If some (or all) of the end of the overlay-with-after-string is made
>> >> invisible, then the situation is much less clear and I could see
>> >> arguments either way, but if I get to choose then I think it makes sense
>> >> to consider that the after string is "attached" to the end of the
>> >> overlay, i.e. if the end of the overlay is invisible then so is the
>> >> after-string.
>> > But that's exactly what happens in your original example.
>> Hmmm.... not that I can see: the overlay covers "text" and none of it
>> is hidden.
> The overlay's end point is _after_ "text", and that's exactly where
> the invisible text starts.  And after-string _follows_ the end of
> "text", so it starts where the invisible text starts.

Yes, but that doesn't mean that the second overlay *covers* the end of
the first.  Whether/when we consider it to cover is something we get
to decide.

Basically, we have:

                      end-of-ol1
                   /              \
    character "t", - after-string - character "\n"
                   \              /
                     start-of-el2

where the middle 3-way thingy has 0 width and we get to treat them as
occurring in any order we like, to some extent (including in several
orders at the same time depending on context).

Currently, it seems that the ordering chosen in this specific example is
something like

   A) character "t", end-of-ol1, start-of-ol2, after-string, character "\n"
or
   B) character "t", start-of-ol2, end-of-ol1, after-string, character "\n"
or
   C) character "t", start-of-ol2, after-string, end-of-ol1, character "\n"

I.e. start-of-ol2 is taken to occur before the after-string, which is
why the after-string is made invisible.

>> I guess you could pay attention to the stickiness of the boundaries
> I don't think stickiness has anything to do with this.

I'm not saying it explains the current behavior, no.  I'm talking about
what kind of model/semantics we could use to justify the current
behavior, and conclude that indeed stickiness can't be used to
justify it.

> I could explain how the particular implementation of these features
> causes the after-string to be skipped in this case, but I prefer that
> we first establish the principles and the concepts.

Agreed.

> The fact that inserting a character behaves in some specific way
> doesn't matter, because the display engine doesn't (and shouldn't)
> consider stickiness, it only considers which display elements
> follow which.

We've used stickiness in various related areas (e.g. in cursor movement)
to try and give some control to the programmer about what should happen
in those borderline cases.

To tell you the truth, I'm not really arguing for the use of
stickiness here.  I'd be perfectly happy with a rule "if the last char
covered by the overlay is visible, then the after-string is also
visible" (which is what I meant by "attached to the end").

>> I meant "if the last few chars covered by the overlay (or the whole
>> text covered by the overlay) is made invisible ...".
> And that's what happens: the overlay's end-point is made invisible.

I said "last few chars", not "end-point".


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31067: 27.0.50; After-string hidden by subsequent invisible text
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 06 Apr 2018 08:25:02 +0000
Resent-Message-ID: <handler.31067.B31067.152300308920810 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31067
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 31067 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 31067-submit <at> debbugs.gnu.org id=B31067.152300308920810
          (code B ref 31067); Fri, 06 Apr 2018 08:25:02 +0000
Received: (at 31067) by debbugs.gnu.org; 6 Apr 2018 08:24:49 +0000
Received: from localhost ([127.0.0.1]:39839 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f4Mfx-0005Pa-4x
	for submit <at> debbugs.gnu.org; Fri, 06 Apr 2018 04:24:49 -0400
Received: from eggs.gnu.org ([208.118.235.92]:33058)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1f4Mfu-0005PL-QZ
 for 31067 <at> debbugs.gnu.org; Fri, 06 Apr 2018 04:24:47 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1f4Mfm-0004MN-HM
 for 31067 <at> debbugs.gnu.org; Fri, 06 Apr 2018 04:24:41 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60293)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1f4Mfm-0004M5-EB; Fri, 06 Apr 2018 04:24:38 -0400
Received: from [176.228.60.248] (port=4505 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1f4Mfl-0005Qx-Ua; Fri, 06 Apr 2018 04:24:38 -0400
Date: Fri, 06 Apr 2018 11:24:53 +0300
Message-Id: <83k1tk214a.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <jwv4lkpjxf2.fsf-monnier+emacsbugs@HIDDEN> (message from Stefan
 Monnier on Thu, 05 Apr 2018 15:15:29 -0400)
References: <jwvmuyi9yj8.fsf@HIDDEN> <8360562db3.fsf@HIDDEN>
 <jwvbmexn8u5.fsf-monnier+emacsbugs@HIDDEN> <83zi2h22pu.fsf@HIDDEN>
 <jwvk1tllkwg.fsf-monnier+emacsbugs@HIDDEN> <83tvsp1qkj.fsf@HIDDEN>
 <jwv4lkpjxf2.fsf-monnier+emacsbugs@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: 31067 <at> debbugs.gnu.org
> Date: Thu, 05 Apr 2018 15:15:29 -0400
> 
> >> Hmmm.... not that I can see: the overlay covers "text" and none of it
> >> is hidden.
> > The overlay's end point is _after_ "text", and that's exactly where
> > the invisible text starts.  And after-string _follows_ the end of
> > "text", so it starts where the invisible text starts.
> 
> Yes, but that doesn't mean that the second overlay *covers* the end of
> the first.  Whether/when we consider it to cover is something we get
> to decide.

You are talking about "covering" here, and I think this discloses the
mental bias in understanding how before- and after-strings work.
Unlike most other overlay properties, they do not supply any
attributes to the characters "covered" by the overlay.  Instead, they
have effect only at two places: the beginning and the end points of
the overlay.  Consequently, we check for them only when we are about
to display something at these two positions.  And in this case, the
end point is invisible, so we never check any after-strings there.

And yes, this is due to the order of checking for various display
features: invisibility is tested before the overlay strings.  But
there's a good reason for that order, and "fixing" this dubious use
case, should we decide doing that, will probably be messy due to the
need to avoid displaying the same overlay string twice.  So I suggest
that we instead accept this as deliberate and correct behavior.

> Currently, it seems that the ordering chosen in this specific example is
> something like
> 
>    A) character "t", end-of-ol1, start-of-ol2, after-string, character "\n"
> or
>    B) character "t", start-of-ol2, end-of-ol1, after-string, character "\n"
> or
>    C) character "t", start-of-ol2, after-string, end-of-ol1, character "\n"
> 
> I.e. start-of-ol2 is taken to occur before the after-string, which is
> why the after-string is made invisible.

We don't test for start-of-ol2, we test whether text at that position
is invisible, for whatever reason (it could be a text property or an
overlay property).

> I'd be perfectly happy with a rule "if the last char covered by the
> overlay is visible, then the after-string is also visible" (which is
> what I meant by "attached to the end").

I tried to explain above why thinking about "covered by" is wrong when
overlay strings are involved.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31067: 27.0.50; After-string hidden by subsequent invisible text
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 06 Apr 2018 12:29:02 +0000
Resent-Message-ID: <handler.31067.B31067.152301772225114 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31067
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 31067 <at> debbugs.gnu.org
Received: via spool by 31067-submit <at> debbugs.gnu.org id=B31067.152301772225114
          (code B ref 31067); Fri, 06 Apr 2018 12:29:02 +0000
Received: (at 31067) by debbugs.gnu.org; 6 Apr 2018 12:28:42 +0000
Received: from localhost ([127.0.0.1]:39921 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f4QTy-0006X0-KX
	for submit <at> debbugs.gnu.org; Fri, 06 Apr 2018 08:28:42 -0400
Received: from pruche.dit.umontreal.ca ([132.204.246.22]:47665)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1f4QTw-0006Wq-HE
 for 31067 <at> debbugs.gnu.org; Fri, 06 Apr 2018 08:28:41 -0400
Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242])
 by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w36CScKJ029239;
 Fri, 6 Apr 2018 08:28:38 -0400
Received: by pastel.home (Postfix, from userid 20848)
 id 550EA604B9; Fri,  6 Apr 2018 08:28:38 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvr2nsfsfq.fsf-monnier+emacsbugs@HIDDEN>
References: <jwvmuyi9yj8.fsf@HIDDEN> <8360562db3.fsf@HIDDEN>
 <jwvbmexn8u5.fsf-monnier+emacsbugs@HIDDEN> <83zi2h22pu.fsf@HIDDEN>
 <jwvk1tllkwg.fsf-monnier+emacsbugs@HIDDEN> <83tvsp1qkj.fsf@HIDDEN>
 <jwv4lkpjxf2.fsf-monnier+emacsbugs@HIDDEN> <83k1tk214a.fsf@HIDDEN>
Date: Fri, 06 Apr 2018 08:28:38 -0400
In-Reply-To: <83k1tk214a.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 06 Apr
 2018 11:24:53 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 5
X-NAI-Spam-Score: 0
X-NAI-Spam-Rules: 2 Rules triggered
	EDT_SA_DN_PASS=0, RV6259=0
X-NAI-Spam-Version: 2.3.0.9418 : core <6259> : inlines <6551> : streams
 <1783363> : uri <2621427>
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

>> >> Hmmm.... not that I can see: the overlay covers "text" and none of it
>> >> is hidden.
>> > The overlay's end point is _after_ "text", and that's exactly where
>> > the invisible text starts.  And after-string _follows_ the end of
>> > "text", so it starts where the invisible text starts.
>> Yes, but that doesn't mean that the second overlay *covers* the end of
>> the first.  Whether/when we consider it to cover is something we get
>> to decide.
> You are talking about "covering" here, and I think this discloses the
> mental bias in understanding how before- and after-strings work.
> Unlike most other overlay properties, they do not supply any
> attributes to the characters "covered" by the overlay.

Note that I was not talking about "after-string covering something" but
about "the invisibility overlay covering the after-string".  For the
`invisible` property, "covering" is very much meaningful, AFAIK.

> And yes, this is due to the order of checking for various display
> features: invisibility is tested before the overlay strings.  But
> there's a good reason for that order, and "fixing" this dubious use
> case, should we decide doing that, will probably be messy due to the
> need to avoid displaying the same overlay string twice.  So I suggest
> that we instead accept this as deliberate and correct behavior.

Here's my use-case:
I have an org-like mode where I add a kind of "summary" of the content
of each section as an after-string on the header (think of it as the
number of sub-sections or the number of words).  This works great as
long as that section is not folded, but as soon as I fold it, the
summary disappears (along with the body, but that part is clearly
intended).  This summary is handy when the section is unfolded but it
would be even more useful when the section is folded.

I wouldn't want to insert those as actual buffer text because they
shouldn't be saved, so it would be a hassle to tweak the save and
auto-save machinery to remove those.

So I'd prefer to keep this as an "unfixed bug".

>> I'd be perfectly happy with a rule "if the last char covered by the
>> overlay is visible, then the after-string is also visible" (which is
>> what I meant by "attached to the end").
> I tried to explain above why thinking about "covered by" is wrong when
> overlay strings are involved.

I'm not talking about the string covering something, I'm talking about
the string's overlay.  IIUC what you're saying is that the connection
between the two is difficult to recover, in the current code.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31067: 27.0.50; After-string hidden by subsequent invisible text
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 06 Apr 2018 13:12:01 +0000
Resent-Message-ID: <handler.31067.B31067.152302027928858 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31067
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 31067 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 31067-submit <at> debbugs.gnu.org id=B31067.152302027928858
          (code B ref 31067); Fri, 06 Apr 2018 13:12:01 +0000
Received: (at 31067) by debbugs.gnu.org; 6 Apr 2018 13:11:19 +0000
Received: from localhost ([127.0.0.1]:39939 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f4R9C-0007VO-Nt
	for submit <at> debbugs.gnu.org; Fri, 06 Apr 2018 09:11:18 -0400
Received: from eggs.gnu.org ([208.118.235.92]:59218)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1f4R9A-0007VB-VK
 for 31067 <at> debbugs.gnu.org; Fri, 06 Apr 2018 09:11:17 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1f4R91-0007jQ-5Z
 for 31067 <at> debbugs.gnu.org; Fri, 06 Apr 2018 09:11:11 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48361)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1f4R91-0007jK-1n; Fri, 06 Apr 2018 09:11:07 -0400
Received: from [176.228.60.248] (port=4912 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1f4R90-0003kl-Fb; Fri, 06 Apr 2018 09:11:06 -0400
Date: Fri, 06 Apr 2018 16:11:03 +0300
Message-Id: <83fu481nvc.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <jwvr2nsfsfq.fsf-monnier+emacsbugs@HIDDEN> (message from Stefan
 Monnier on Fri, 06 Apr 2018 08:28:38 -0400)
References: <jwvmuyi9yj8.fsf@HIDDEN> <8360562db3.fsf@HIDDEN>
 <jwvbmexn8u5.fsf-monnier+emacsbugs@HIDDEN> <83zi2h22pu.fsf@HIDDEN>
 <jwvk1tllkwg.fsf-monnier+emacsbugs@HIDDEN> <83tvsp1qkj.fsf@HIDDEN>
 <jwv4lkpjxf2.fsf-monnier+emacsbugs@HIDDEN> <83k1tk214a.fsf@HIDDEN>
 <jwvr2nsfsfq.fsf-monnier+emacsbugs@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.0 (------)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: 31067 <at> debbugs.gnu.org
> Date: Fri, 06 Apr 2018 08:28:38 -0400
> 
> > You are talking about "covering" here, and I think this discloses the
> > mental bias in understanding how before- and after-strings work.
> > Unlike most other overlay properties, they do not supply any
> > attributes to the characters "covered" by the overlay.
> 
> Note that I was not talking about "after-string covering something" but
> about "the invisibility overlay covering the after-string".  For the
> `invisible` property, "covering" is very much meaningful, AFAIK.

Indeed.  The problem here is that the invisibility overlay covers the
position where displaying the after-string should be considered.

> Here's my use-case:
> I have an org-like mode where I add a kind of "summary" of the content
> of each section as an after-string on the header (think of it as the
> number of sub-sections or the number of words).  This works great as
> long as that section is not folded, but as soon as I fold it, the
> summary disappears (along with the body, but that part is clearly
> intended).  This summary is handy when the section is unfolded but it
> would be even more useful when the section is folded.
> 
> I wouldn't want to insert those as actual buffer text because they
> shouldn't be saved, so it would be a hassle to tweak the save and
> auto-save machinery to remove those.
> 
> So I'd prefer to keep this as an "unfixed bug".

Fine with me (I still hope that leaving such issues will some day
attract volunteers who'd like to do their share of hacking the display
code).

Alternatively, you could, either:

 . separate the invisible text and the after-string with some
   character, or
 . use the 'invisible' text property instead of an overlay

> > I tried to explain above why thinking about "covered by" is wrong when
> > overlay strings are involved.
> 
> I'm not talking about the string covering something, I'm talking about
> the string's overlay.  IIUC what you're saying is that the connection
> between the two is difficult to recover, in the current code.

No, I'm saying that the only connection is the 2 end-points of the
overlay.  The fact that some text is or isn't in-between is
irrelevant.  Talking about "covered text" in this case is detrimental
to understanding how the feature works, because it tends to force us
to think about after-string as being in some sense "related" to the
"covered" text.  It isn't.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31067: 27.0.50; After-string hidden by subsequent invisible text
Resent-From: Drew Adams <drew.adams@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 06 Apr 2018 15:40:02 +0000
Resent-Message-ID: <handler.31067.B31067.152302920017374 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31067
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>
Cc: 31067 <at> debbugs.gnu.org
Received: via spool by 31067-submit <at> debbugs.gnu.org id=B31067.152302920017374
          (code B ref 31067); Fri, 06 Apr 2018 15:40:02 +0000
Received: (at 31067) by debbugs.gnu.org; 6 Apr 2018 15:40:00 +0000
Received: from localhost ([127.0.0.1]:40532 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f4TT5-0004WA-Te
	for submit <at> debbugs.gnu.org; Fri, 06 Apr 2018 11:40:00 -0400
Received: from userp2120.oracle.com ([156.151.31.85]:40838)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drew.adams@HIDDEN>) id 1f4TT4-0004Vx-0Z
 for 31067 <at> debbugs.gnu.org; Fri, 06 Apr 2018 11:39:58 -0400
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1])
 by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w36F401S127408;
 Fri, 6 Apr 2018 15:39:51 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com;
 h=mime-version :
 message-id : date : from : sender : to : cc : subject : references :
 in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26;
 bh=wIsAl/h+SXa5fvjbIC1k60j6k6v95URXnktOw2zTraU=;
 b=v+i8rI5mCBNJV5hl4Cnys5v0hjxHJftrzKgokacdyrI1RhStLH6itjuktqZolfyYVQ9T
 /qVcNpFzWaqQ5Q+H1Hf8eNlS6P1q1zHc8nJq0d8nYuDWDJFHdLRYgQEhO2v0SliSbXt4
 Q0mRCxQfrKrlLWJcbR6qx33pwSPl+UT0N2Lr+wNdgpT9DNuXiFf2FOWMh0hOjm/0osU4
 PbbRW8FEh8jld8pS3iqEs2DV8mZpuj0TV1NJdMxFxuRjImu6EaDW4BjQLDM12lQfIRyN
 5oWnVmocRbxX1P4U/yx1YLbHmWcPAYDMiMonX2OBfTU/Pnn8zweaTYHtsUDYsBZ0oL5S TQ== 
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74])
 by userp2120.oracle.com with ESMTP id 2h5k4bdme9-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 06 Apr 2018 15:39:51 +0000
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235])
 by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w36FdowP016309
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Fri, 6 Apr 2018 15:39:50 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7])
 by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w36Fdld4010855;
 Fri, 6 Apr 2018 15:39:48 GMT
MIME-Version: 1.0
Message-ID: <c5808065-9fdd-4c18-9e92-f53d45b78f94@default>
Date: Fri, 6 Apr 2018 15:39:45 +0000 (UTC)
From: Drew Adams <drew.adams@HIDDEN>
References: <<jwvmuyi9yj8.fsf@HIDDEN>> <<8360562db3.fsf@HIDDEN>
 <jwvbmexn8u5.fsf-monnier+emacsbugs@HIDDEN>> <<83zi2h22pu.fsf@HIDDEN>
 <jwvk1tllkwg.fsf-monnier+emacsbugs@HIDDEN>> <<83tvsp1qkj.fsf@HIDDEN>
 <jwv4lkpjxf2.fsf-monnier+emacsbugs@HIDDEN>> <<83k1tk214a.fsf@HIDDEN>>
In-Reply-To: <<83k1tk214a.fsf@HIDDEN>>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1  (1003210) [OL
 16.0.4666.0 (x86)]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8854
 signatures=668697
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0
 malwarescore=0
 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=925
 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.0.1-1711220000 definitions=main-1804060153
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

> You are talking about "covering" here, and I think this discloses the
> mental bias in understanding how before- and after-strings work.
> Unlike most other overlay properties, they do not supply any
> attributes to the characters "covered" by the overlay.  Instead, they
> have effect only at two places: the beginning and the end points of
> the overlay.  Consequently, we check for them only when we are about
> to display something at these two positions.  And in this case, the
> end point is invisible, so we never check any after-strings there.

Sounds like that information is important for a user's mental
model.  Is it presented in the manual?  If not, perhaps it
should be.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31067: 27.0.50; After-string hidden by subsequent invisible text
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 06 Apr 2018 17:12:02 +0000
Resent-Message-ID: <handler.31067.B31067.152303466525160 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31067
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Drew Adams <drew.adams@HIDDEN>
Cc: 31067 <at> debbugs.gnu.org, monnier@HIDDEN
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 31067-submit <at> debbugs.gnu.org id=B31067.152303466525160
          (code B ref 31067); Fri, 06 Apr 2018 17:12:02 +0000
Received: (at 31067) by debbugs.gnu.org; 6 Apr 2018 17:11:05 +0000
Received: from localhost ([127.0.0.1]:40554 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f4UtF-0006Xk-74
	for submit <at> debbugs.gnu.org; Fri, 06 Apr 2018 13:11:05 -0400
Received: from eggs.gnu.org ([208.118.235.92]:44708)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1f4UtD-0006XF-7k
 for 31067 <at> debbugs.gnu.org; Fri, 06 Apr 2018 13:11:03 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1f4Ut3-0005z5-FJ
 for 31067 <at> debbugs.gnu.org; Fri, 06 Apr 2018 13:10:57 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20,T_RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53947)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1f4Ut3-0005y4-9W; Fri, 06 Apr 2018 13:10:53 -0400
Received: from [176.228.60.248] (port=1455 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1f4Ut2-0005qf-Jm; Fri, 06 Apr 2018 13:10:53 -0400
Date: Fri, 06 Apr 2018 20:10:50 +0300
Message-Id: <838ta01crp.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <c5808065-9fdd-4c18-9e92-f53d45b78f94@default> (message from Drew
 Adams on Fri, 6 Apr 2018 15:39:45 +0000 (UTC))
References: <<jwvmuyi9yj8.fsf@HIDDEN>> <<8360562db3.fsf@HIDDEN>
 <jwvbmexn8u5.fsf-monnier+emacsbugs@HIDDEN>> <<83zi2h22pu.fsf@HIDDEN>
 <jwvk1tllkwg.fsf-monnier+emacsbugs@HIDDEN>> <<83tvsp1qkj.fsf@HIDDEN>
 <jwv4lkpjxf2.fsf-monnier+emacsbugs@HIDDEN>> <<83k1tk214a.fsf@HIDDEN>>
 <c5808065-9fdd-4c18-9e92-f53d45b78f94@default>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.0 (------)

> Date: Fri, 6 Apr 2018 15:39:45 +0000 (UTC)
> From: Drew Adams <drew.adams@HIDDEN>
> Cc: 31067 <at> debbugs.gnu.org
> 
> Sounds like that information is important for a user's mental
> model.  Is it presented in the manual?  If not, perhaps it
> should be.

It will only make sense to document this if there's an agreement that
this is the correct behavior.  It doesn't sound we have such an
agreement at this time.

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.