Helm (and other popup windows) cause buffers to jump around.

[jordwalke]

If your cursor in a file is towards the bottom of the screen, then when any popup window is shown (which-key, or helm) - the popup window will need to move your cursor "out of the way", and that causes your files that you're editing to jump around. That is super confusing and distracting. You could be reading the text in those files as you open a popup window.

This is an issue with the default spacemacs config, and I also tried a couple of other emacs config settings.

  (custom-set-variables
   '(scroll-preserve-screen-position t)
   '(scroll-conservatively 1000)
   '(scroll-margin 3)
   )

[justbur]

May I ask what you would like to happen in this case?

[bmag]

Copied my comment from #1281, so discussion can continue here:

I think it's an Emacs thing. When creating a new window (e.g. for Helm), Emacs needs to split an existing window. But what if the point ("point" means the cursor's position in the window's buffer) is hidden from view? Then Emacs scrolls the window so the point is visible again. You can set the variable window-split-keep-point to nil, but that will change the behavior only for the split-window-below function and other functions that rely on it. For other scenarios, I don't of a simple way to prevent Emacs from scrolling the window.

You can read about window-split-keep-point and related stuff here, or via C-h v window-split-keep-point RET.

[bmag]

Also, @justbur's question is a good one. What would you like to happen?

[jordwalke]

I don't know anything about implementation. This is approximately day two of even trying emacs for me. But the effect you're going for (or IMHO the one that users really appreciate), is like Sublime's Command+P (or Atom's now). It's as if there's a drop down (or drop "up" if docked to the bottom) overlay. In Sublime, that overlay would never change the scroll position of the text buffers underneath it.

One way that I imagined you could do this, is to (before opening the popup (helm, or whatever)), compute the height of the popup. Then you see if the current cursor position in any of the other windows is going to be under where the popup will appear. If so, you temporarily move those cursor positions out of the way for the duration of the popup.

I can confirm that this approach would work because if you manually move your text buffers' cursor positions out of the way of helm (or whatever), it will never disturb the scroll position of your non-popup buffers.

For the reasons you suggested, I thought it would be best to do this cursor record/restore process from some kind of a popup framework so that it doesn't change the behavior for non-popups.

[a13ph]

You can do without conditional:
compute new visible part of buffer position to be based on two point positions:

• in a file, the usual one
• % in a visible part of buffer

[bmag]

@jordwalke I believe it is possible to do as you suggested, but not simple.

First, split-window is the function that actually does the splitting, so you will need to write a before advice for split-window that moves the cursor positions out of the way. Using advice is generally discouraged, but in this case I think you don't have a good alternative.
Second, you need to restore the cursor positions to their original locations in an appropriate time.
Third, you need a way to decide when splitting a window should trigger the temporary relocation of cursors.

Part 1 can be done. Part 3 can also be done, getting a good design will require some thought. Part 2, though, can be tricky, beacuse the "appropriate time" can be hard to define. I guess that hooking into window-configuration-change-hook to find out when the popup window is deleted, and then restoring the cursor locations will work correctly for some popups. But I fear that there are several popups where it is expected of the window's cursor to move, for example helm-swoop and sometimes compilation buffers.

First, split-window is the function that actually does the splitting, so you will need to write a before advice for split-window that moves the cursor positions out of the way.
Second, you need to restore the cursor positions to their original locations in an appropriate time.
Third, you need a way to decide when splitting a window should trigger the temporary relocation of cursors.

Part 1 can be done. Part 3 can also be done, getting a good design will require some thought. Part 2, though, can be tricky, beacuse the "appropriate time" can be hard to define. I guess that hooking into window-configuration-change-hook to find out when the popup window is deleted, and then restoring the cursor locations will work correctly for some popups. But I fear that there are several popups where it is expected of the window's cursor to move, for example helm-swoop and sometimes compilation buffers.

I think it will take a proof of concept to see how feasible your suggestion is. Writing one will require some effort and time, but unfortunately I don't have enough spare time for that. You (or someone else) can try writing such a system yourself, if you feel up to it.

[jordwalke]

I just started learning emacs a couple of days ago. It will be some time before I would be ready to tackle this one. It would be great though :D

[failable]

That's really a good question, I'm waiting for any good news!!! In most situation I think I don't need the cursor to be visible.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!