From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#31067: 27.0.50; After-string hidden by subsequent invisible text Date: Fri, 06 Apr 2018 16:11:03 +0300 Message-ID: <83fu481nvc.fsf@gnu.org> References: <8360562db3.fsf@gnu.org> <83zi2h22pu.fsf@gnu.org> <83tvsp1qkj.fsf@gnu.org> <83k1tk214a.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1523020213 31818 195.159.176.226 (6 Apr 2018 13:10:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 6 Apr 2018 13:10:13 +0000 (UTC) Cc: 31067@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Apr 06 15:10:08 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f4R82-00088h-0K for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Apr 2018 15:10:06 +0200 Original-Received: from localhost ([::1]:54697 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f4RA7-0003Sc-LE for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Apr 2018 09:12:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50849) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f4R9y-0003Q6-Mw for bug-gnu-emacs@gnu.org; Fri, 06 Apr 2018 09:12:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f4R9t-0008DS-Vk for bug-gnu-emacs@gnu.org; Fri, 06 Apr 2018 09:12:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60276) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f4R9t-0008DI-RZ for bug-gnu-emacs@gnu.org; Fri, 06 Apr 2018 09:12:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f4R9t-0007WM-Ly for bug-gnu-emacs@gnu.org; Fri, 06 Apr 2018 09:12:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Apr 2018 13:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31067 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 31067-submit@debbugs.gnu.org id=B31067.152302027928858 (code B ref 31067); Fri, 06 Apr 2018 13:12:01 +0000 Original-Received: (at 31067) by debbugs.gnu.org; 6 Apr 2018 13:11:19 +0000 Original-Received: from localhost ([127.0.0.1]:39939 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f4R9C-0007VO-Nt for submit@debbugs.gnu.org; Fri, 06 Apr 2018 09:11:18 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59218) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f4R9A-0007VB-VK for 31067@debbugs.gnu.org; Fri, 06 Apr 2018 09:11:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f4R91-0007jQ-5Z for 31067@debbugs.gnu.org; Fri, 06 Apr 2018 09:11:11 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48361) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f4R91-0007jK-1n; Fri, 06 Apr 2018 09:11:07 -0400 Original-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 ) id 1f4R90-0003kl-Fb; Fri, 06 Apr 2018 09:11:06 -0400 In-reply-to: (message from Stefan Monnier on Fri, 06 Apr 2018 08:28:38 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:144947 Archived-At: > From: Stefan Monnier > Cc: 31067@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.