emacs for code editing
22 points by knl
22 points by knl
I was hoping for good advice on useful things like LSP integration or workflow to make jumping from compiler errors to affected code quickly.
Instead I got someone who says not to use the mouse and then spends the rest of the article on a menagerie of movement commands combined with modal editing to make them less keystroke hungry to compensate for not just reaching for the mouse.
People have been saying stuff like this for decades and I bought it as a young programmer. It took me years to realize that it’s rubbish. I still use eMacs for some things from muscle memory but I recognize it as sunk cost on my part and happily use the mouse as a large part of my navigation. I rarely write code in it though.
Different strokes for different folks, but it's definitely not rubbish in general/for everyone. Decade-long Vim user here, and it drives me bananas when I have to use the mouse to edit text - I find that it's slower, that the context switch to using a mouse is jarring, and that selecting the text I want is very fiddly.
Beyond that, model editing is about a lot more than moving the cursor and selecting text - it's an entire language of text manipulation commands which you can't replicate with the mouse alone (multiple cursors, repeat action, macros, swap case, increment/decrement) in addition to powerful movement (structural movement, as mentioned in the article).
If it doesn't work for you, that's fine! I'm sure you're faster and more comfortable with a mouse, and I'm faster and more comfortable with a keyboard.
I’m quite fluent in vi as well as emacs, though those skills have been rotting for a long time. It’s important not to confuse the sunk cost of your fluency with facts about user interface design. Nothing you mention requires or even benefits from modal editing. Multiple cursors? VSCode does that just fine. Repeat action? Macros? Emacs’s macros are vastly better than Vi’s, and we can do much better yet. And structured movement with the mouse is for some reason basically ignored. If you’ve ever used a serious mouse based CAD like Ashlar Vellum’s tools you’ll have some idea of what’s possible for pointing at things effectively with the mouse.
There is a place for micro modes like devil-mode’s comma binding or vscode’s command palette, but even those may just be steps on the way to a good mode less design.
I don't believe I am confusing sunk cost with UI design - I believe I edit text much more effectively now, using a model editor, than I did back when I didn't use a model editor.
You dismiss repeat action and macros as being better in Emacs, but I don't think that's particularly relevant - Emacs macros aren't mouse-based, are they? In which case I'm not sure what your argument is, you're just bringing up a keyboard based system you think is better, which is fine.
Also, your suggestion for a serious mouse based tool is a CAD editor, not a text editor! I'm not saying a keyboard based model editor is better for CAD, I'm saying for a solid set of people it's better for text/code. And maybe there are some super powerful mouse-based code editors that are very effective for other people (ACME? VS Code power users?)! Not for me though.
I just wanted to push back on what I interpreted your comment to be saying, which I thought was that model editors in general are rubbish and people use them out of sunk cost. They work really well for some people, myself included.
There's not necessarily one perfect UX for everyone, so it's a good thing we have so many text editing options.
I don't believe I am confusing sunk cost with UI design - I believe I edit text much more effectively now, using a model editor, than I did back when I didn't use a model editor.
I think the point they're making is: is that because modal editing is actually so much more effective from a UI design perspective or are you specifically better w/ modal editing because you've sunk a lot into learning that particular paradigm?
So your response here doesn't really address their point, it's exactly what their point is responding to in the first place (though you hadn't yet said it in this conversation).
You're right, I could have been clearer on that point: For me, over the medium-long term, model editing is more effective.
Model editing had a larger learning curve, but for me, also a higher ceiling on the effectiveness I was able to achieve. I was faster after using model editing for a couple of years than I had been using the mouse for years before that, and my model editing continued to get better in subsequent years, whereas I feel like I had previously reached the limit on my mouse-based editing. (I'm not saying it takes years to get faster either, I just know for sure I was faster after a few years. I think I had regained most of my speed after a few months).
Your mileage may of course vary, editing styles are very personal, and different things work for different people.
I still use eMacs for some things from muscle memory [...]. I rarely write code in it though.
This has been my experience as well. I have been working on a Macbook and it was an almost painless migration as some actions are abstracted by Emacs (file exploring and manipulation, for example). It's a bit sad that I find myself doing almost everything from within Emacs but programming. I just pay Jetbrains and use their IDEs.
Personally I would prefer using free software to do software, but I only have so much time to craft my own tools.
Here's some advice re: compiler errors. Use compilation-mode (M-x compile, n and p to jump around to errors, g to recompile after fixing issues). It parses compiler output and allows you to jump to files quickly and easily. It works best in conjunction with project-mode in my experience, and both are bundled with emacs. You don't even need LSP, although emacs comes with an LSP client as well nowadays (eglot).
Note that not only does compilation mode (mis-named, really) work with error and warning output from many compilers, but also from things such as grep -Hn or anything else you can use to output lines starting with filepath:linenumber:. Just write the output to a file and then open the file in emacs.
And both with M-x grep and M-x occur you can use next-error to go to the next hit (no matter what window your cursor is in) just like with M-x compile
Modal editing, movement and jumping, marks, registers, and macros... are you SURE this isn't actually about vim?
Not that vim has a monopoly on these things. But this post just doesn't sound very emacs-y to me.
marks, registers, and macros...
Those have always existed in Emacs.
As to the modal editing, well... is there something more emacs-y than a user remaking entirely the keybindings to suit their own needs?