bug#58793: 28.1.90; Emacs tries to recenter / rescroll when it hits hidden org emphasis

bug#58793: 28.1.90; Emacs tries to recenter / rescroll when it hits hidden org emphasis

[Ihor Radchenko]

Hello,

I am forwarding the following bug report from Org mailing list
(https://orgmode.org/list/CA+FzMhahT16w5KPi3hgq8Gn7wnb+PjcNuS_ULk_jroGLHBVBaw@mail.gmail.com)
It appears to be related to Emacs.
I can also reproduce on my side and I have seen similar scrolling quirks
myself in the daily usage.

-------------

To reproduce this:
1. Load the repro emacs settings.
2. Scroll down in a buffer, such that top of buffer is not visible on
screen.
3. Create an emphasized word at the beginning of the 2nd visual-line in a
visually-wrapped line.
4. Move your point to the start of that emphasized word

It's a little difficult to describe, so I'll give an example. Assume
that the visual-line wrapping is happening at the place indicated by
"$".

```
So, if this were one long line, then this is the first visual line,$
/whereas/ this is the second visual line in the paragraph, and you'd place$
point on the italicized "w" in the word "whereas". That triggers the bug.
```

What happens next is that emacs thinks the point is no longer on screen
and tries to scroll to fix that. Under vanilla emacs, it will just
recenter the point. This still is misbehaving but not terribly. However,
with
smooth-scrolling as mentioned above, the behavior is worse. The window
scrolls up and point jumps to the top of the window.

Reproed this with the following: emacs -Q
with the following:
```
(setq org-hide-emphasis-markers t)

(org-mode)
(visual-line-mode 1)

;; Without this, emacs will still show bug by calling recenter, but the
effect is particularly egregious with these settings (i.e. smooth scrolling)
(setq scroll-conservatively 101
      scroll-preserve-screen-position t
      scroll-margin 0)
```

Best,
Ihor

In GNU Emacs 28.1.90 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, cairo version 1.16.0)
 of 2022-07-17 built on localhost
Repository revision: f5218385c064aa959650bfe49ca32795270851eb
Repository branch: emacs-28
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Gentoo Linux


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#58793: 28.1.90; Emacs tries to recenter / rescroll when it hits hidden org emphasis

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Date: Wed, 26 Oct 2022 07:59:14 +0000
> 
> So, if this were one long line, then this is the first visual line,$
> /whereas/ this is the second visual line in the paragraph, and you'd place$
> point on the italicized "w" in the word "whereas". That triggers the bug.

But you are not on the italicized "w", are you?  Try "C-x =", and you
will see.

The question is why.  Hmm...

bug#58793: 28.1.90; Emacs tries to recenter / rescroll when it hits hidden org emphasis

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> So, if this were one long line, then this is the first visual line,$
>> /whereas/ this is the second visual line in the paragraph, and you'd place$
>> point on the italicized "w" in the word "whereas". That triggers the bug.
>
> But you are not on the italicized "w", are you?  Try "C-x =", and you
> will see.

(I assume that you have managed to confirm the bug; I can provide a more
detailed recipe if necessary)

Yes, C-x = reports invisible "/".

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#58793: 28.1.90; Emacs tries to recenter / rescroll when it hits hidden org emphasis

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: 58793@debbugs.gnu.org
> Date: Thu, 27 Oct 2022 04:24:17 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> So, if this were one long line, then this is the first visual line,$
> >> /whereas/ this is the second visual line in the paragraph, and you'd place$
> >> point on the italicized "w" in the word "whereas". That triggers the bug.
> >
> > But you are not on the italicized "w", are you?  Try "C-x =", and you
> > will see.
> 
> (I assume that you have managed to confirm the bug; I can provide a more
> detailed recipe if necessary)

Yes, I see the recentering scroll.  I will look into that shortly.

bug#58793: 28.1.90; Emacs tries to recenter / rescroll when it hits hidden org emphasis

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Date: Wed, 26 Oct 2022 07:59:14 +0000
> 
> 1. Load the repro emacs settings.
> 2. Scroll down in a buffer, such that top of buffer is not visible on
> screen.
> 3. Create an emphasized word at the beginning of the 2nd visual-line in a
> visually-wrapped line.
> 4. Move your point to the start of that emphasized word
> 
> It's a little difficult to describe, so I'll give an example. Assume
> that the visual-line wrapping is happening at the place indicated by
> "$".
> 
> ```
> So, if this were one long line, then this is the first visual line,$
> /whereas/ this is the second visual line in the paragraph, and you'd place$
> point on the italicized "w" in the word "whereas". That triggers the bug.
> ```
> 
> What happens next is that emacs thinks the point is no longer on screen
> and tries to scroll to fix that. Under vanilla emacs, it will just
> recenter the point. This still is misbehaving but not terribly. However,
> with
> smooth-scrolling as mentioned above, the behavior is worse. The window
> scrolls up and point jumps to the top of the window.
> 
> Reproed this with the following: emacs -Q
> with the following:
> ```
> (setq org-hide-emphasis-markers t)
> 
> (org-mode)
> (visual-line-mode 1)
> 
> ;; Without this, emacs will still show bug by calling recenter, but the
> effect is particularly egregious with these settings (i.e. smooth scrolling)
> (setq scroll-conservatively 101
>       scroll-preserve-screen-position t
>       scroll-margin 0)
> ```

Thanks, I hope I fixed this now.

bug#58793: 28.1.90; Emacs tries to recenter / rescroll when it hits hidden org emphasis

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks, I hope I fixed this now.

I confirm the fix.
Thanks!

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#58793: 28.1.90; Emacs tries to recenter / rescroll when it hits hidden org emphasis

[Eli Zaretskii]

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

bug#58793: 28.1.90; Emacs tries to recenter / rescroll when it hits hidden org emphasis

[Eli Zaretskii]

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

bug#58793: 28.1.90; Emacs tries to recenter / rescroll when it hits hidden org emphasis

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

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

Thanks for the explanation!
AFAIU, there is no way to avoid this and also use invisible text
somewhere not at bol/eol. The best we can do is minimizing the chance
to trigger this redisplay behaviour.

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

Noted. Though I feel that we really need to have A LOT of invisible text
to hit the issue frequently. (here, I was just digging through old bug
reports in Org mailing list; it is not something people often complain
about)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>