From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#31067: 27.0.50; After-string hidden by subsequent invisible text Date: Fri, 06 Apr 2018 08:28:38 -0400 Message-ID: References: <8360562db3.fsf@gnu.org> <83zi2h22pu.fsf@gnu.org> <83tvsp1qkj.fsf@gnu.org> <83k1tk214a.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1523017629 27395 195.159.176.226 (6 Apr 2018 12:27:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 6 Apr 2018 12:27:09 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 31067@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Apr 06 14:27:05 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 1f4QSP-00070k-4m for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Apr 2018 14:27:05 +0200 Original-Received: from localhost ([::1]:51601 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f4QUU-0008Gv-Km for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Apr 2018 08:29:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49271) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f4QUL-0008G9-R7 for bug-gnu-emacs@gnu.org; Fri, 06 Apr 2018 08:29:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f4QUI-0007wK-Me for bug-gnu-emacs@gnu.org; Fri, 06 Apr 2018 08:29:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60257) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f4QUI-0007w6-In for bug-gnu-emacs@gnu.org; Fri, 06 Apr 2018 08:29:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f4QUI-0006XW-5A for bug-gnu-emacs@gnu.org; Fri, 06 Apr 2018 08:29:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Apr 2018 12:29:02 +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.152301772225114 (code B ref 31067); Fri, 06 Apr 2018 12:29:02 +0000 Original-Received: (at 31067) by debbugs.gnu.org; 6 Apr 2018 12:28:42 +0000 Original-Received: from localhost ([127.0.0.1]:39921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f4QTy-0006X0-KX for submit@debbugs.gnu.org; Fri, 06 Apr 2018 08:28:42 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:47665) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f4QTw-0006Wq-HE for 31067@debbugs.gnu.org; Fri, 06 Apr 2018 08:28:41 -0400 Original-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 Original-Received: by pastel.home (Postfix, from userid 20848) id 550EA604B9; Fri, 6 Apr 2018 08:28:38 -0400 (EDT) In-Reply-To: <83k1tk214a.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 06 Apr 2018 11:24:53 +0300") 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-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:144944 Archived-At: >> >> 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