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: Thu, 05 Apr 2018 21:00:28 +0300 Message-ID: <83tvsp1qkj.fsf@gnu.org> References: <8360562db3.fsf@gnu.org> <83zi2h22pu.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1522951150 18348 195.159.176.226 (5 Apr 2018 17:59:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 5 Apr 2018 17:59:10 +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 Thu Apr 05 19:59:06 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 1f49A9-0004fj-1v for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Apr 2018 19:59:05 +0200 Original-Received: from localhost ([::1]:45353 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f49CE-0003Pg-Ei for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Apr 2018 14:01:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42397) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f49C6-0003Os-Oh for bug-gnu-emacs@gnu.org; Thu, 05 Apr 2018 14:01:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f49C2-0005io-45 for bug-gnu-emacs@gnu.org; Thu, 05 Apr 2018 14:01:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59980) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f49C2-0005ij-00 for bug-gnu-emacs@gnu.org; Thu, 05 Apr 2018 14:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f49C1-0000cu-PF for bug-gnu-emacs@gnu.org; Thu, 05 Apr 2018 14:01: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: Thu, 05 Apr 2018 18:01: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.15229512262360 (code B ref 31067); Thu, 05 Apr 2018 18:01:01 +0000 Original-Received: (at 31067) by debbugs.gnu.org; 5 Apr 2018 18:00:26 +0000 Original-Received: from localhost ([127.0.0.1]:39644 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f49BR-0000c0-Nn for submit@debbugs.gnu.org; Thu, 05 Apr 2018 14:00:25 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51301) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f49BQ-0000bm-L5 for 31067@debbugs.gnu.org; Thu, 05 Apr 2018 14:00:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f49BH-0005KQ-Fs for 31067@debbugs.gnu.org; Thu, 05 Apr 2018 14:00:19 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43993) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f49BH-0005KM-Bn; Thu, 05 Apr 2018 14:00:15 -0400 Original-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 ) id 1f49BG-0004me-PT; Thu, 05 Apr 2018 14:00:15 -0400 In-reply-to: (message from Stefan Monnier on Thu, 05 Apr 2018 11:55:43 -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:144932 Archived-At: > From: Stefan Monnier > Cc: 31067@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.