> I was also extremely bothered by the fact that the cursor cannot live outside the current viewport and scrolling the buffer would drag the cursor as well.

I can see how that would be annoying. I can also see why the developers might not have noticed. When I'm in Emacs, I tend to navigate using the keyboard, which means I scroll by moving the cursor and dragging the viewport with it.

So they probably added the ability to scroll without moving the cursor so Emacs would have the feature. But if they never really used it, they wouldn't have noticed the shortcomings in their implementation.

Sorry for the rambling, not sure if I really had a point to make ;)

If well configured, mouse support can be handful when navigating code. There is a niche editor called Acme[1] that is almost "mouse-only", where even Return won't put you in the next line :)

When using Emacs, my workflow was very keyboard-centric, but sometimes navigation was a pain (even with tags and whatnot).

[1]https://www.youtube.com/watch?v=dP1xVpMPn8M

Oh sure, I'm not saying it's not a useful feature. Just an observation of how different usage patterns can lead to blindspots.

> Emacs is amazing. I stopped using it a few years ago because I became lazy to keep my configuration and extensions up-to-date.

> But I would love to go back to it, to be honest.

What helps me not get bogged down in versioning, is to let someone else deal with it.

For example, Debian and NixOS each package many Emacs packages. I just use their versions, and treat it like any other piece of software managed by the OS.

Alternatively you could try things like Doom, which I think handles versioning.

Knee-Deep in Elisp?

not sure when it was implemented, but to keep the cursor position fixed while scrolling

(setq scroll-preserve-screen-position 1)

Unfortunately, that's not what OP wants. What OP wants is that when they scroll, the position of the cursor remains at the same position in the buffer (the contents), even when that means that it leaves the currently visible screen.

What scroll-preserve-screen-position determines, is whether the point/cursor stays at the same visual position in the screen — i.e. if for instance your cursor was in the middle of the screen, it will stay in the middle when you scroll.

OP needs the currently non-existent scroll-preserve-buffer-position.

You could just set mark when scrolling starts. Then, next cursor move jump back to mark first.

Some heuristics to make it fully behave. Multiple scroll events should not modify mark, for example. Mouse click does not jump back to mark. Etc.

The lack of "scroll-preserve-buffer-position" has been a very minor pet peeve for me for multiple years, and for some reason this very simple solution just never occurred to me.

I can't believe I didn't think of this. I'm already using marks to keep track of position when I scroll, it's just all manual right now.

I'll likely mess around with some hooks in my config this weekend and see if this is actually feasible, or if it comes with caveats I'm not seeing right now. I guess it would need to account for multiple windows open into the same buffer too.

I'm convinced the edge cases will dominate this code, but the general idea seems straight forward. If you get this working, please share. Not something I think I want, per se, but I could be mistaken on seeing it work. :)

Well done. You have confirmed what they said:

> and the solution was something like "you are using it wrong - you need to use marks instead".

My point was you could automate it. You were not using it wrong. Instead, my point is that you can make using it act like you want.

Agreed, was thinking the same.

"Instead of setting the mark in order to operate on a region, you can also use it to remember a position in the buffer (by typing C-<SPC> C-<SPC>), and later jump back there (by typing C-u C-<SPC>)." -- https://www.gnu.org/software/emacs/manual/html_node/emacs/Se...

Sure, but then every time the user does anything that might scroll the point off the screen, he has to remember to C-<SPC> C-<SPC> first. Installing a new habit that has to activate before such a wide range of editing operations can take a lot of time, during which the user is less productive because part of his attention is devoted to installing the new habit.

You're right. In practice I usually C-/ (undo) C-g / (redo) to get back to where I was; which is something you can do after you've lost your place in the file, but it assumes to previously made some change in that location.

From C-h v

    This variable was introduced, or its default value was changed, in version 22.1 of Emacs.
    Probably introduced at or before Emacs version 20.1.