Comment by _hardwaregeek | Hacker News Reader

Comment by _hardwaregeek | Hacker News Reader

Parent Full thread

This is a super dumb example, but I hate that scrolling is tied to cursor. Like if I'm gasp using the mouse to scroll through a file in emacs, the cursor has to stay in the viewport. If I scroll past the viewport, the cursor moves to the viewport. In IntelliJ (which has such good emacs keybindings I can use it for a lot of my work), the opposite is true: when I scroll away from my cursor, it stays there and when I start typing again, my viewport moves to my cursor not vice versa.

It's a small thing but it shows emacs' age. When emacs was written, GUI cursors weren't a thing. Scrolling wasn't a thing. Of course the cursor and the viewport would be connected. There wasn't any other way to move the viewport. Basically emacs needs to be somewhat GUI native.

Emacs should also be more discoverable. It's hard to incrementally learn key commands. I hate that the default for M-x is just a blank line. It's really intimidating. Having some sort of fuzzy search/history like Helm makes M-x so much easier to use.

Basically emacs needs to get UI and UX people to give it a refresh. Nothing outlandish, just get it into the 21st century.

I think it's possible to implement this as an extension on top of evil? trigger a bookmark when the user starts scrolling, jump back to the bookmark on keystroke in insert mode.

but yeah, there's generally a problem with the UI/UX -- like as a consequence of the problem you're describing, you have to clear your current selection before scrolling to paste from the kill buffer. it's all foibles you learn about and adjust to but it makes the environment feel unpolished on a first impression.

spacemacs and doom have a better impression out of the box but there are just some core problems that they can't fix with a clever configuration. one that frustrates me regularly is auto-complete (company) triggering a network call that's bound to time out (because of user error) and the whole editor hanging for the duration because the completion call happened in the same thread as the UI. actually, the single threaded nature of most of emacs is probably my biggest complaint...

Oh yeah you could definitely implement this with some nice config. But that's the problem: only insane people like fiddling with configuration that much.

I know my gateway to emacs was spacemacs. Except spacemacs, when I used it, was slow as heck. When VSCode feels snappier than emacs, something's wrong.

People talk about rewrites far too often but I wouldn't mind a significant rearchitecture/rewrite of emacs. Stuff like this^[1] makes me think it's long overdue.

[1]: https://www.facebook.com/notes/daniel-colascione/buttery-smo...

definitely. i agree with all of that. i have high hopes for remacs.

Whenever I want to keep my place but look at another part of the file, I do C-x 2, mess around in the other window, then C-x 0 when I want to go back to my place.

I hate that in other editors if I'm keeping the cursor in one place and scrolling to look at another, that if I want to change something in that other place I have to lose the cursor position I'm trying to hold onto.

It's because scrolling doesn't actually make sense in emacs or vim, if you've put some time into learning how to use them.

In vim, for example, you would be much better off navigating with the keyboard than the mouse. You can leave bookmarks all over the file and jump between them with 2 keystrokes. There are also a multitude of navigation controls ({, }, gg, G, etc.) that save you the time of moving your hand in between your mouse and keyboard.

If you want to use your mouse, maybe vim/emacs aren't for you -- sublime or vs code will probably serve you better.

I'm genuinely curious: do you not read through code from top to bottom? That's a very common thing that I do, and using the mouse is a comfortable way of accomplishing it.

If you want to go to the next page (screen) of code, isn’t the keyboard just as comfortable? If you want to go down until you find the thing you’re looking for, wouldn’t a search using the keyboard be potentially more comfortable?

I like how I can control the rate at which I scroll with the mouse more easily than with the keyboard. It's a more intuitive movement that I can adjust to match the speed of my reading.

The point is that reading code from top to bottom is not a reason to need or prefer a mouse. Other people prefer using a keyboard and find moving through pages more intuitive than scrolling.

Different people have different preferences, so clearly it is a reason to prefer a mouse.

I don’t use my mouse with Emacs, but I’m not going to tell someone else they’re wrong for wanting to. I’m beginning to see why people feel the Emacs community is less-than-welcoming.

Of course different people have different preferences. I don’t tell anybody that the way they prefer is wrong! I don’t say there is a reason to prefer the keyboard either. But being what it is doesn’t make Emacs broken. You can definitely read code from top to bottom on it.

> It's because scrolling doesn't actually make sense in emacs or vim, if you've put some time into learning how to use them. In vim, for example, you would be much better off navigating with the keyboard than the mouse.

Is this coming from a workstation-oriented mindset? On laptops with touchpads, scrolling with your "mouse" makes a ton of sense even for seasoned touch typists. I don't always use it for scrolling, but I frequently do. However when I'm sitting in front of a workstation with a traditional keyboard and mouse arrangement, I do avoid the mouse.

Eh, Vim and Kakoune user here for the last ~15 years, I love scrolling with my mouse and keyboard. Keyboard for when I'm navigating. Mouse wheel for when I'm just skimming code, idly looking for something.

The fact is scrolling with a mouse moves much faster while still seeing what I'm doing. You can't scroll line by line quickly with a keyboard. There's no variable speed (that I've ever seen, at least). However with a mouse I can alternate between fast and slow. Really nice for scanning large piles of text where you don't know exactly what you're looking for.

Sure I could jump a screen length at a time if I wanted, but then my eyes have to jump bottom to top to bottom to top every time I jump. I find it difficult to track where I am. Page jumping tends to ruin context, even with a handful of lines as context.

With that said though, I have seen some really nice Terminal renderers that will smear the cursor when you jump. It looks like it would help a lot to keep the visual context.

I use Emacs all day, every day, and I use the mouse to scroll.

I've done the "look ma no mouse" thing where you just use your keyboard. Heck, I used to have an emacs config where scrolling would scroll through my undo/redo tree^[1], which lemme tell you, confuses the hell out of other people using your computer.

But ultimately sometimes executing some annoying combo of C-v/C-s/M-f/M-b is less ergonomic than using the wonderful invention that is scrolling. Especially if you want to aimlessly scan through code instead of purposefully navigate.

I suspect part of the reason for emacs being a hard sell is the reputation of emacs being an all or nothing platform. You're supposed to not use the mouse, do everything in emacs, write elisp to make everything super automated and awesome. And sure, you can do that! But it's okay to be a bad emacs user. It's okay to use the mouse. It's okay to not write elisp. It's okay to use other apps. VSCode doesn't come with a religion. I don't think emacs should either.

[1]: Inspired by this XKCD: https://xkcd.com/1806/

> This is a super dumb example, but I hate that scrolling is tied to cursor. Like if I'm gasp using the mouse to scroll through a file in emacs, the cursor has to stay in the viewport.

I don't quite see an easy way of fixing that without making it a user-controlled option, though. For example, in text-mode editors it is still common to not have the text cursor scroll past the viewport.

Reply on news.ycombinator.com