Hacker News new | past | comments | ask | show | jobs | submit login

I'd make cursors be positioned within the document instead of on the screen. Currently, Emacs does not support off-screen cursors. If you attempt to scroll a cursor off screen, it will move within the document to stay on screen. This behavior is contrary to all modern text editors, and there is no good workaround. I once made a serious effort to start using Emacs, but ultimately stopped because of the annoying cursor behavior. (There were other annoyances, but none so fundamental and unfixable.)



It (kinda) has multiple cursors per document if you split the frame and display the buffer twice. For longer source files I find myself splitting horizontally, editing in the left pane, and using the right pane for secondary movement and reference.

I have a buffer manager that can switch the displayed buffer quickly, when I switch to a different buffer and back again, it retains it's "secondary" cursor position that is separate from the other view.


It is possible to emulate this in Emacs Lisp. I've created a package to that extent, see http://ankarstrom.se/~john/etc/emacs/scroll-without-point.el. (I've made a few changes to it the last couple of weeks that I have yet to upload, though.) I should probably publish it somewhere else eventually, but I've always felt it to be a bit of a hack. Still, I use it and it works well 99% of the time.



This might be a dumb question, but how would an off-screen cursor work in a terminal? According to my understanding of the way terminal emulators/ncurses work, the cursor must be positioned somewhere in the screen, even if it isn't visible.


ncurses lets you move the cursor to arbitrary positions, and also lets you hide it. And you can disable echo, so you can type without the cursor having any influence on what you see. This means you can treat the terminal cursor as though it's a software-rendered cursor in a GUI app and apply all the same rules. But nobody considered doing this when Emacs was first written (maybe it wasn't possible then), so the assumption that the cursor is always on screen is difficult to change.


I'd be happy to break terminal mode (which I almost never use) in exchange for getting this feature.


whereas I use emacs exclusively in terminal mode, and would be rather upset to it no longer supported :)


Fair enough, but a straightforward solution would be to just not allow off-screen cursors in terminal mode, and allow them in GUI mode.


This is a really interesting case of Emacs being so old that its default (and only in this case) behavior is just unable to comprehend current computer technology and usage. I think I am correct in saying that the lack of capabilities to have horizontal scrolling of a screen was an absolute hard limit of the teletype and terminal era. It should not be difficult to add such capability, but more than the obviously connected portions of Emacs’ code could implicitly rely on the assumptions that come from the impossibility of horizontally extending text.


I'll try to use the more common Windows/MacOS terms for it, but in emacs I often have the same file opened in two different panes within one window or two separate windows. I do this when I want to be looking at one part of a file while editing another.

Markers are used to mark a different point in the file and one can pop their location to a previous mark.


Putting cursors within the document does not preclude supporting different cursors for different windows.


This still annoys me slightly after nearly 20 years of using Emacs.

In response to keypresses, it doesn't bother me too much, as I'm used to the Windows-style behaviour of PgUp/PgDn/etc. moving the caret, much as the Mac behaviour of not doing that is sometimes useful. But for mouse wheel scrolling, which I do a lot - precisely because on Windows this typically does not move the caret! - having point follow along has never felt right.


> But for mouse wheel scrolling, which I do a lot - precisely because on Windows this typically does not move the caret! - having point follow along has never felt right.

Iam pretty sure you can customzize that if you want.

> scroll-preserve-screen-position is a variable defined in ‘C source code’.

> Its value is ‘keep’ > Original value was nil

> Controls if scroll commands move point to keep its screen position unchanged.

> A value of nil means point does not keep its screen position except > at the scroll margin or window boundary respectively.

> A value of t means point keeps its screen position if the scroll > command moved it vertically out of the window, e.g. when scrolling > by full screens. If point is within ‘next-screen-context-lines’ lines > from the edges of the window, point will typically not keep its screen > position when doing commands like ‘scroll-up-command’/‘scroll-down-command’ > and the like.


You’re misunderstanding. In those other apps the behavior is this: you open a document. You put the cursor on line 3 column 3. You use the mouse wheel or trackpad to scroll down to line 600. You hit cursor right. The cursor is now on line 3 column 4.

In emacs the cursor would be somewhere around line 600 instead.


It should be possible to save the cursor position, hide it if it moves away from view during scrolling, and restore it back on any command but scrolling, or at least at the firs cursor-movement command.


Conversely, I curse heavily at Mac programs where I can page down or scroll for a while, only to have an arrow press jump way the heck back in the document.


Curious, why would it matter that the cursor stays where you were when paging down?


When you scroll away you can jump back by hitting anything on your keyboard. Also you can stay where you are, by clicking anywhere. It is a useful feature, that enables you to scroll to your heart's content.


The exact behavior isn't hugely important (although I think off-screen cursors are a useful feature). What matters is consistency between applications. There's no realistic scenario where I do everything in Emacs, so Emacs has to behave in the same way as other applications. If not, I risk data loss or corruption because I might fail to notice the cursor ending up somewhere I didn't expect. This is especially likely to happen with a feature like off-screen cursors that I use only occasionally.


You might know, but you can set marks to go back when you scroll off. I have to admit it's not as convenient as the cursor just behaving like that automatically, though.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: