Extreme stuttering when a pointer is located on collapsed block

[everydayanchovies]

In org mode, when any buffer has its cursor located on a collapsed source block such that the cursor is partially visible (cut-off from the top), scrolling becomes extremely slow.

To reproduce:

1. open an org mode buffer with a source block larger than the window height,
2. split the window vertically
3. with the bottom window fully occupied by the block, switch to the top window
4. collapse the block from the top window, so that cursor is partially cut-off in bottom window
5. scroll from the top window

See video attached.

Screen.Recording.2025-05-27.at.12.51.44.mov

[jdtsmith]

Thanks, I can reproduce this slow-down, which is slight on my system, not sure where in your movie you see "extreme" stuttering. Unfortunately, it is not occurring inside ultra-scroll, as the core scroll function timings remain the same (<1ms for me). So the slowdown must be in re-display itself, when a buffer is displayed twice, and in one window it has non-zero vscroll. In fact, everything seems to slow down (completion, etc.) with a half-hidden cursor. Do you find that as well?

Do you see any errors ala #31? Can you describe more about what happens when ultra-scroll is disabled and the slowdown does not occur? Does the partially visible cursor jump onto a full line in the lower window?

[everydayanchovies]

I see no errors, but I confirm that I could not profile the issue with the profiler.

The stuttering becomes worse with increasing document size (consistent with an issue in redisplay).
For my use-case, if any such buffer is open, I can no longer move around in my documents until i exit the buffer. The screen would freeze for multiple seconds per scroll attempt.

When ultra-scroll is disabled, I can never get the cursor to be cut off. That appears to be the issue.
Maybe it is possible to ensure that lines are always fully on screen when scrolling is over?

[everydayanchovies]

Screen.Recording.2025-05-27.at.16.48.16.mov

[everydayanchovies]

Notice how the ellipsis disappears once I scroll the bottom window.

[jdtsmith]

Yes, I see the same. In fact tons of things are much slower when the cursor gets into this "half visible" state for two (or more) windows showing the same buffer. And a taller window with larger buffer contents does show increased slowdown, I can confirm. This is very likely an ancient redisplay bug. If you are up for it, you could work up a small reproducer (omitting org-mode and ultra-scroll) and submit a bug report. set-window-vscroll can be used to offset a cursor like that.

For me, with a half-visible cursor, without ultra-scroll, it starts slow, then something brings the cursor in the non-selected window back into view, and it speeds up again. Sometimes even with ultra-scroll active this happens. I've pushed a somewhat heavy-handed commit which looks for other windows displaying the current buffer and zeroes vscroll there; please give a test and report how it works for you.

[everydayanchovies]

Amazing, thank you so much for the speedy fix!

I would submit a bug report but only in a couple of months, I am very short on time at the moment.

[pkryger]

In fact tons of things are much slower when the cursor gets into this "half
visible" state for two (or more) windows showing the same buffer.

@jdtsmith, I've been observing lag when point is not fully visible as well. In
fact it happens when there's is a single window, or other windows are showing
different buffers as well. To reproduce:

0. Open a long buffer that doesn't fit in a window
1. Place a point in a line X, where X > 1.
2. Scroll such that line X - 1 is half visible
3. Move point to line X - 1, using for example backward-char (C-b)

At this point my Emacs becomes pretty laggy. I have been trying to advice
commands that move point to a partially visible line (for example see
here),
and I achieved more or less satisfying results. Yet I am not sure if this is
the way to go, since the list is long, and 3-rd party packages can add more
point moving commands. On top of that the list I came up with is likely not
exhaustive and is more than likely biased towards commands I have a habit of
using. And my habits likely doesn't cover all possibilities.

Another alternative I've been pondering is to use post-command-hook to see if
point has ended up in a partially visible line, but have not tried that yet.

N.B. The solution I am
using
also alleviates a little jerk when first line is not fully visible and a
command moves point vertically (i.e., next-line, previous-line), that I
described
here.

Please let me know if I should log a separate issue for the lag when point is
not fully visible. And perhaps for the jerk when first line is not fully
visible.

[jdtsmith]

Interesting, I can confirm I can get a half-visible cursor with your prescription (though not with previous-line), and things do slow way down, so @everydayanchovies' issue must just be a special case of this. What is the value of make-cursor-line-fully-visible for you?

Here's an even easier way to get this, no special scrolling mode required:

• place cursor on first visible line
• M-: (set-window-vscroll nil 0.5)

Can people please confirm? I feel like this slowdown is new behavior in v30. Do your older Emacs versions exhibit the same problem?

I suspect the "jerk" you mention is just generic lag exhibited in ultra-scroll prior to the cursor being fully visible.

A quick profile shows that redisplay_internal is the hot spot; so definitely a bug. We should open a bug report in case it's already been noted or resolved. Would be helpful to gather some evidence and do some testing with emacs -Q. Is that something you could help with?

[pkryger]

I can confirm I can get a half-visible cursor with your prescription

Great news - it is reproducible! 😎

[...] though not with previous-line [...]

My guess this is because previous-line (as well as next-line) cause to
reset vscroll causing the "jerk" (more on it below).

[...] so @everydayanchovies' issue must just be a special case of this.

This is my guess too.

What is the value of make-cursor-line-fully-visible for you?

The value of make-cursor-line-fully-visibles is t on both Emacs-30.1.50 built
from this
commit
and Emacs-29.4 built from this
commit.

Here's an even easier way to get this, no special scrolling mode required:

• place cursor on first visible line
• M-: (set-window-vscroll nil 0.5)

I can confirm this works as a reproduction for me as well.

I suspect the "jerk" you mention is just generic lag exhibited in ultra-scroll prior to the cursor being fully visible.

@jdtsmith I followed your
suggestion
from discussion in #20 that this is a reset caused by line-move. Hence the
previous-line and next-line response above. To prevent the jerk I added
advices to latter commands (and couple others) to only reset vscroll when first
line is not fully visible (see
here). I
have tried playing with value of auto-window-vscroll to eliminate jerk but
had no success and fallen back to advices. I think I like non-jerking
behaviour better. Also when comparing to what happens with emacs -Q which
also "jerks" on line-move when the first line is not fully visible ¯\_(ツ)_/¯.

A quick profile shows that redisplay_internal is the hot spot [...]

I think this fits into my most recent observation: when the frame is small (say
32 by 80) the issue is barely noticeable on my macBook Air M2 (both on
Emacs-29.4 and Emacs-30.1.50). But when I move to a normal editing mode (88 by
156) then it's really noticeable.

Would be helpful to gather some evidence and do some testing with emacs -Q. Is that something you could help with?

I can help with that. So far I managed to reproduce the issue (on a large file)
after evaluating the following snippet:

use-package ultra-scroll
  :vc (:url "https://github.com/jdtsmith/ultra-scroll.git" :rev :newest)
  :custom
  (scroll-conservatively 101) ; important for jumbo images
  (scroll-margin 0)
  (ultra-scroll-hide-functions '(hl-line-mode global-hl-line-mode))

  :config
  (ultra-scroll-mode))

Please let me know how I can help further.

[jdtsmith]

Thanks for these thoughts. For submitting a real bug report, they will want a reproducer with the fewest moving parts and no 3rd party packages. So ideally just setting vscroll and timing the movement to the beginning of the line, for example.

And to confirm, slowdown behavior is the same on v39 and v30? Which build do you use?

[pkryger]

So I managed to reproduce with emacs -Q. Steps to reproduce:

0. emacs -Q
1. Eval: (setq scroll-step 1) (otherwise window recenters everytime point
   goes to a partially visible line)
2. Open large buffer
3. Make frame large (mine is 89x361)
4. Open a long file (more than (window-height))
5. Place point in a first column of line X
6. Scroll that the line X-1 is partially visible
7. Type C-b (backward-char), repeat

I profiled it and the same redisplay_internal comes back as a hotspot.

A short note: I think it would be great if there was an option for Emacs to
just reset vscroll every time point goes out of scope (as opposed to recenter
when value of scroll-step is 0).

On Emacs-mac 30.1.50, GUI mode.

[jdtsmith]

Great. Here's a more explicit reproducer along these lines. Just put in a file and emacs -Q -l test.el:

;;; -*- lexical-binding: t -*-
(eval-when-compile (require 'cl-lib))
(set-frame-height nil 90)
(setq scroll-step 1)
(find-library "simple.el")
(forward-line 500)
(recenter-top-bottom 0)
(cl-labels ((bench (end &optional cnt)
	      (benchmark-run (or cnt 2)
		(save-excursion
		  (while (< (point) end)
		    (forward-char)
		    (redisplay))))))
  (let* ((end (pos-eol))
	 (bn (bench end))
	 (bv (progn (set-window-vscroll nil 0.5)
		    (bench end))))
    (message "Timing forward-char to end of line:\n w/o VSCROLL - %S, with VSCROLL - %S\n slowdown: %0.2fx"
	     bn bv (/ (car bv) (car bn)))))

I get ~150x slowdown. Quite noticeable.

Can you guys try this on an NS and/or Linux build? I wonder if this is an emacs-mac only issue (that's what I use too)? If that turns out to be the case, I'll ask you open an issue on https://github.com/jdtsmith/emacs-mac instead. @everydayanchovies what build are you on?

This is a good find. In fact I now believe that pretty much every time I get "weird unexpected lagginess" (once or twice a week for me), it's because somewhere, in some window, on some frame, often far away, you have a half visible cursor. Fix that and the lag goes away. So thanks for helping make the connection. We could try to work around this by minimizing the chances of landing with non-zero vscroll, but that's not ideal. You can't control what other packages will do, and sensible image scrolling in particular simply requires vscroll.

We will get to the bottom of this.

[pkryger]

@jdtsmith I managed to reproduce your results on my Emacs-mac 30.1.50. Running
the test script shows - a very similar - slowdown of ~150x.

But I couldn't reproduce it on Emacs-plus 30.1 (is that NS?) on macOS Sonoma
15.5 on MacBook Air M2.

I have manually run a profiler on Emacs-plus and it highlit the same
hotspot. It shows that redisplay_internal took 90% of the time but point
movement in a partially visible line was snappy (on 102x360 frame).

I guess we should open a new issue in https://github.com/jdtsmith/emacs-mac ?

I installed Emacs-plus 30.1 (I have 4 Emacsen installed now 🫣) with:

brew tap d12frosted/emacs-plus
brew install --skip-link emacs-plus
ln -s /opt/homebrew/Cellar/emacs-plus@30/30.1/Emacs.app /Applications/Emacs-plus.app

(not sure if the last step is strictly necessary though).

I had to modify the test code to add (pixel-scroll-precision-mode) before
running benchmark. This is to alleviate default line by line Emacs-plus
scrolling. Then run the test with:

/Applications/Emacs-plus.app/Contents/MacOS/Emacs -Q -l test.el

It produced the following result:

Timing forward-char to end of line:
 w/o VSCROLL - (0.028788 0 0.0), with VSCROLL - (0.00834 0 0.0)
 slowdown: 0.29x

[everydayanchovies]

@everydayanchovies what build are you on?

This is a good find. In fact I now believe that pretty much every time I get "weird unexpected lagginess" (once or twice a week for me), it's because somewhere, in some window, on some frame, often far away, you have a half visible cursor. Fix that and the lag goes away. So thanks for helping make the connection. We could try to work around this by minimizing the chances of landing with non-zero vscroll, but that's not ideal. You can't control what other packages will do, and sensible image scrolling in particular simply requires vscroll.

We will get to the bottom of this.

Ah great! I run your build (jdsmith/emacs-mac) at commit 4caf8199ea11305ce5f6ca0a380cf18d200d5039
Which has been very nice to use by the way, thank you for maintaining it.