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 11:24:53 +0300 Message-ID: <83k1tk214a.fsf@gnu.org> References: <8360562db3.fsf@gnu.org> <83zi2h22pu.fsf@gnu.org> <83tvsp1qkj.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1523003015 10532 195.159.176.226 (6 Apr 2018 08:23:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 6 Apr 2018 08:23:35 +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 10:23:31 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 1f4Mef-0002dV-Ps for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Apr 2018 10:23:31 +0200 Original-Received: from localhost ([::1]:35418 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f4Mgl-00024X-Ct for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Apr 2018 04:25:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52492) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f4MgD-0001fO-Hn for bug-gnu-emacs@gnu.org; Fri, 06 Apr 2018 04:25:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f4MgA-0004qc-D6 for bug-gnu-emacs@gnu.org; Fri, 06 Apr 2018 04:25:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60175) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f4MgA-0004qW-9D for bug-gnu-emacs@gnu.org; Fri, 06 Apr 2018 04:25:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f4MgA-0005Q5-2H for bug-gnu-emacs@gnu.org; Fri, 06 Apr 2018 04:25:02 -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 08:25: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.152300308920810 (code B ref 31067); Fri, 06 Apr 2018 08:25:02 +0000 Original-Received: (at 31067) by debbugs.gnu.org; 6 Apr 2018 08:24:49 +0000 Original-Received: from localhost ([127.0.0.1]:39839 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f4Mfx-0005Pa-4x for submit@debbugs.gnu.org; Fri, 06 Apr 2018 04:24:49 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:33058) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f4Mfu-0005PL-QZ for 31067@debbugs.gnu.org; Fri, 06 Apr 2018 04:24:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f4Mfm-0004MN-HM for 31067@debbugs.gnu.org; Fri, 06 Apr 2018 04:24:41 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60293) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f4Mfm-0004M5-EB; Fri, 06 Apr 2018 04:24:38 -0400 Original-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 ) id 1f4Mfl-0005Qx-Ua; Fri, 06 Apr 2018 04:24:38 -0400 In-reply-to: (message from Stefan Monnier on Thu, 05 Apr 2018 15:15:29 -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:144940 Archived-At: > From: Stefan Monnier > Cc: 31067@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.