unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 31067@debbugs.gnu.org
Subject: bug#31067: 27.0.50; After-string hidden by subsequent invisible text
Date: Thu, 05 Apr 2018 15:15:29 -0400	[thread overview]
Message-ID: <jwv4lkpjxf2.fsf-monnier+emacsbugs@gnu.org> (raw)
In-Reply-To: <83tvsp1qkj.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 05 Apr 2018 21:00:28 +0300")

>> >> 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





  reply	other threads:[~2018-04-05 19:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-05  2:28 bug#31067: 27.0.50; After-string hidden by subsequent invisible text Stefan Monnier
2018-04-05  9:49 ` Eli Zaretskii
2018-04-05 12:23   ` Stefan Monnier
2018-04-05 13:38     ` Eli Zaretskii
2018-04-05 15:55       ` Stefan Monnier
2018-04-05 18:00         ` Eli Zaretskii
2018-04-05 19:15           ` Stefan Monnier [this message]
2018-04-06  8:24             ` Eli Zaretskii
2018-04-06 12:28               ` Stefan Monnier
2018-04-06 13:11                 ` Eli Zaretskii
     [not found]             ` <<83k1tk214a.fsf@gnu.org>
2018-04-06 15:39               ` Drew Adams
2018-04-06 17:10                 ` Eli Zaretskii
     [not found] <<jwvmuyi9yj8.fsf@iro.umontreal.ca>

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwv4lkpjxf2.fsf-monnier+emacsbugs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=31067@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).