bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#58793: 28.1.90; Emacs tries to recenter / rescroll when it hits hidd


From: Eli Zaretskii
Subject: bug#58793: 28.1.90; Emacs tries to recenter / rescroll when it hits hidden org emphasis
Date: Fri, 28 Oct 2022 09:50:34 +0300

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: 58793@debbugs.gnu.org
> Date: Fri, 28 Oct 2022 04:07:33 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Thanks, I hope I fixed this now.
> 
> I confirm the fix.
> Thanks!

Thanks for testing, I'm therefore closing the bug.

Btw, you wrote to the Org list that this issue has nothing to do with
Org, but that is inaccurate.  The bug was triggered by the fact that a
screen line started with invisible text, and point was inside that
invisible text.  Emacs display code assumes in a lot of places that
the position of point is somewhere between the positions of the first
and the last glyph of a screen line which displays the cursor.
Invisible text at the beginning or end of a screen line violates that
assumption, if point is inside invisible text, because invisible text
doesn't produce glyphs on the screen.  Violating that assumption
delivers a fatal blow to many redisplay optimizations that reuse
previous display (instead of redrawing everything anew); one of such
optimizations is for the situation when nothing's changed on display
except that point moved.  The display engine is still capable of
dealing with such unusual situations, but it is likely to recenter the
window in these cases, something that you find jarring.

So by using invisible text too much, Org does risk triggering such
situations more frequently.  Since the result is not fatally wrong,
just aesthetically annoying, I could say "wontfix", because fixing
this is notoriously complicated, and risks introducing new exciting
bugs (I hope I didn't introduce any this time).  In this case I was
lucky to be able to find a reasonable solution, but I cannot guarantee
that for any similar issue in the future.  After all, arguably Emacs
just copes with the unusual situation by falling back on the only
fail-safe redisplay mechanism we have.  So it is not a bug, strictly
speaking, just unusual and unexpected behavior.

Please keep this in mind as you introduce features into Org and
elsewhere which use invisible text.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]