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: Thu, 05 Apr 2018 15:15:29 -0400 Message-ID: References: <8360562db3.fsf@gnu.org> <83zi2h22pu.fsf@gnu.org> <83tvsp1qkj.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1522955651 27004 195.159.176.226 (5 Apr 2018 19:14:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 5 Apr 2018 19:14:11 +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 Thu Apr 05 21:14:07 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 1f4AKj-0006tl-P9 for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Apr 2018 21:14:06 +0200 Original-Received: from localhost ([::1]:49065 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f4AMp-00058f-8I for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Apr 2018 15:16:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56845) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f4AMj-000586-FP for bug-gnu-emacs@gnu.org; Thu, 05 Apr 2018 15:16:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f4AMc-00065u-SM for bug-gnu-emacs@gnu.org; Thu, 05 Apr 2018 15:16:09 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60011) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f4AMc-00065g-O1 for bug-gnu-emacs@gnu.org; Thu, 05 Apr 2018 15:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f4AMc-0002IZ-CV for bug-gnu-emacs@gnu.org; Thu, 05 Apr 2018 15:16: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: Thu, 05 Apr 2018 19:16: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.15229557348799 (code B ref 31067); Thu, 05 Apr 2018 19:16:02 +0000 Original-Received: (at 31067) by debbugs.gnu.org; 5 Apr 2018 19:15:34 +0000 Original-Received: from localhost ([127.0.0.1]:39675 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f4AM9-0002Hr-NH for submit@debbugs.gnu.org; Thu, 05 Apr 2018 15:15:33 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:53117) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f4AM8-0002Hi-11 for 31067@debbugs.gnu.org; Thu, 05 Apr 2018 15:15:33 -0400 Original-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 Original-Received: by ceviche.home (Postfix, from userid 20848) id D10576637D; Thu, 5 Apr 2018 15:15:29 -0400 (EDT) In-Reply-To: <83tvsp1qkj.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 05 Apr 2018 21:00:28 +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, RV6258=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6258> : inlines <6550> : streams <1783294> : uri <2621027> 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:144936 Archived-At: >> >> 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