GNU bug report logs - #31067
27.0.50; After-string hidden by subsequent invisible text

Previous Next

Full log

Message #17 received at 31067 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 31067 <at> debbugs.gnu.org
Subject: Re: bug#31067: 27.0.50;
 After-string hidden by subsequent invisible text
Date: Thu, 05 Apr 2018 11:55:43 -0400

>> > IOW, the question is what should happen when the end-point of the
>> > overlay with after-string is in invisible text?
>> 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.

I guess you could pay attention to the stickiness of the boundaries, but
in my example the end of the overlay-with-after-string is not sticky, so
you could say that it ends right after "t" and not on the immediately
following "(dimensionless) point".  Also I changed my test so that the
beginning of the invisible overlay is not sticky (so that the
"(dimensionless) point" between "t" and "\n" is supposedly not affected
by this overlay):

(defun foo ()
  (interactive)
  (with-current-buffer "*scratch*"
    (add-to-invisibility-spec '(foo . t))
    (let ((beg (point)))
      (insert "text")
      (let ((ol1 (make-overlay beg (point))))
        (overlay-put ol1 'after-string "!after!")
        (overlay-put ol1 'evaporate t)))
    (let ((beg (point)))
      (insert "\nhidden")
      (let ((ol1 (make-overlay beg (point) nil t)))
        (overlay-put ol1 'invisible 'foo)
        (overlay-put ol1 'evaporate t)))))

but the result is still the same.  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).

> Btw, "some or all of the end" is a strange wording,

Indeed, I added "or all" after the fact and did it poorly.  I meant "if
the last few chars covered by the overlay (or the whole text covered
by the overlay) is made invisible ...".


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.