Funny to see the love for “Fill Paragraph”. I use it a lot as well, and funnily enough never really realised how important it’s become for my daily text editing.
It can get annoying when programming, because it treads code like prose. For that purpous, I have replace M-q with
(defun local/indent-defun ()
"Call `indent-region' on defun.
If point is in a comment, call `fill-region' instead."
(interactive)
(if (nth 4 (syntax-ppss)) ; if in a comment
(fill-paragraph)
(save-mark-and-excursion
(save-restriction
(narrow-to-defun)
(indent-region (point-min) (point-max))
(whitespace-cleanup-region (point-min) (point-max))))))```
It was giving VS Code a whirl that drove that home for me. I hit M-q out of pure muscle memory and realized it didn’t work, then went searching through the command palette for the equivalent and found nothing. Much later I discovered there’s an extension for it but it feels bizarre to me not to have that built in.
I think the coolest aspect of Emacs is that it’s its own interpreter. It’s a customizable Lisp interpreter for editing text! The power of its extensions like Org is not in not just their existence, but the fact that they could be built. You don’t really write Emacs extensions or plugins. You just write more Emacs.
Yes, this. It is a model of how I wish more of modern computing worked; Emacs is inspectable right down to the primitives, without having to exit Emacs.
During this time, I dabbled with vim. However, the modal nature of editing felt foreign. At times, I’d try out a tutorial, but it never stuck
That seems to be something that most (non evil mode) Emacs users have in common.
For those of you looking to improve your editing experience, I recommend persevering through the initial foreign feel of modal editing. The payoff is well worth it.
I was into vim before emacs, and love love loved modal editing. I hated how manual VSCode and other editors felt by comparison. I wish emacs were more powerful natively in this regard. But the main deal breaker for me was that vim still required some level of “task switching” with the “Unix as an IDE” philosophy – as someone with ADHD, the kitchen sink nature of emacs keeps me productive. And there’s always evil of course.
I know a lot of people like it, but in my eyes Evil seems out of plae in Emacs. Yes, it’s technically possible, but there are better ways to combine modal editing with the already-existing conventions in Emacs. Objed and lispy are two interesting attempts at this, in my eyes.
FWIW, I use a package that marries lispy and evil: https://github.com/noctuid/lispyville and have had a pretty good experience for ~6 months. You could argue that I’m missing out on some core lispy-editing experience though by approacing it from an evil origin point
At the end of the day we’re all human (I think), and tribalism is part of the package. It seems to show up when people invest in one thing vs another, whether the investment is time, money, emotion, brain rewiring (muscle memory!), etc…
As someone who actively used both at one point, and was probably on the proficient to advanced end of the spectrum in terms of editing experience with both, I cringe at claims that one editing style clearly outclasses the other in terms of efficiency, productivity, or whatever. I’d wager that 90% of the time in a keyboard-oriented editor, we navigate by word or line when we’re not navigating by search.
Arguing about editors reminds me of unproductive language disagreements, when we talk in terms of absolutes instead of trade offs.
Agree about 90 claim. After I’ve moved my arrow keys to home row via https://manybutfinite.com/post/home-row-computing/, I became almost as productive at raw text editing anywhere as I was in Emacs or Vim. Well, you also need ace jump and multiple cursors for coding specifically.
I think that some people portray Emacs and Lisp as “holy” and above criticism—although this is certainly a minority of those communities—so others respond with criticism of Emacs’s poor defaults and hostility to new users. People get into heated arguments about their favorite things, and that includes text editors.
It’s mostly team signalling. For some reason a bunch of nerds decided that Emacs/VIM is their Ford/(Holden|Chev) and they need to play silly tribal games.
I would be glad to use emacs as my main editor, but, unfortunately, whenever you need to work with any modern front-end framework the support from emacs is quite basic. But really, I blame frameworks… .jsx and .vue are both a mess as far as syntax parsing goes.
I use emacs for web development, but in my case that’s mostly just HTML and CSS. All the front-end, back-end frameworks always seemed too confusing and appearing/disappearing so quickly, that I loose track of them. Have you used external packages, or as you talking about built-in support?
I use external packages for both, and they do a fine job highlighting syntax but fail short on more “intelligent” features like autocompletion and “go to definition”. Autoformatting is also often hit-or-miss… VSCode is better in this respect, but it’s slower and much less convenient in the actual text editing part, for me at least (maybe I’m just used to emacs and too lazy to configure VSCode properly).
Make sure that expand region hooks into that, because semantic expand region, coupled with multiple cursors, is the most effective editing feature there is.
What I found most remarkable about this story is that the author actually switched after so many years.
I programmed with notepad - yes, plain Windows notepad - (and later, gedit on Linux) for years. In 2007, I finally took the dive and started vim just because I was changing everything and no longer had the basic thing I used for so long. But like I still use the mouse and arrow keys and such, even with the embracing of the modal editor just because old habits die hard.
Now, after 13 years of vim, I don’t think I could switch to anything again just because I’m so used to it this way. So remarkable the author was able to change!
The workflow you describe for Swiper sounds nice. It makes me wish I could try that in VS Code.
Now that I think about it, IntelliJ IDEA’s Find in Path window, which I like a lot, supports the same workflow. Not only does it list your search results (live as you type) in the context of the lines they were in, it also has a second pane that shows your currently-selected result in the context of its file. After typing your search, you can press the Up and Down arrow keys to switch your selected result and instantly preview another one. (You didn’t mention it, but I see that Swiper also previews your selected result, just with a different layout.)
Funny to see the love for “Fill Paragraph”. I use it a lot as well, and funnily enough never really realised how important it’s become for my daily text editing.
It can get annoying when programming, because it treads code like prose. For that purpous, I have replace
M-qwithhm, I’ve never experienced this behaviour. In the language modes I use (Scheme, Python, C, JS), it simply fills out the text in comments, only.
It was giving VS Code a whirl that drove that home for me. I hit
M-qout of pure muscle memory and realized it didn’t work, then went searching through the command palette for the equivalent and found nothing. Much later I discovered there’s an extension for it but it feels bizarre to me not to have that built in.I think the coolest aspect of Emacs is that it’s its own interpreter. It’s a customizable Lisp interpreter for editing text! The power of its extensions like Org is not in not just their existence, but the fact that they could be built. You don’t really write Emacs extensions or plugins. You just write more Emacs.
Yes, this. It is a model of how I wish more of modern computing worked; Emacs is inspectable right down to the primitives, without having to exit Emacs.
That seems to be something that most (non evil mode) Emacs users have in common.
For those of you looking to improve your editing experience, I recommend persevering through the initial foreign feel of modal editing. The payoff is well worth it.
I’m fully capable of using
viand Vim and I still prefer Emacs. I don’t use Evil mode either.I can use modal text editing. I just prefer not to.
I was into vim before emacs, and love love loved modal editing. I hated how manual VSCode and other editors felt by comparison. I wish emacs were more powerful natively in this regard. But the main deal breaker for me was that vim still required some level of “task switching” with the “Unix as an IDE” philosophy – as someone with ADHD, the kitchen sink nature of emacs keeps me productive. And there’s always evil of course.
Out of curiosity, which language(s) do you work in currently?
In my day job, mostly Python and R, lots of SQL and rarely C, C#, and node.
In side projects, mainly python and Erlang
Ooo - thank you!
I know a lot of people like it, but in my eyes Evil seems out of plae in Emacs. Yes, it’s technically possible, but there are better ways to combine modal editing with the already-existing conventions in Emacs. Objed and lispy are two interesting attempts at this, in my eyes.
FWIW, I use a package that marries lispy and evil: https://github.com/noctuid/lispyville and have had a pretty good experience for ~6 months. You could argue that I’m missing out on some core lispy-editing experience though by approacing it from an evil origin point
Although I do not prefer emacs day-to-day, I never understood the disdain for it. It must be the cool thing to do/say on the Internet.
At the end of the day we’re all human (I think), and tribalism is part of the package. It seems to show up when people invest in one thing vs another, whether the investment is time, money, emotion, brain rewiring (muscle memory!), etc…
In-group/out-group dynamics, mostly? Getting incensed by some other person’s choice of tools is pretty weird, when you think about it.
As someone who actively used both at one point, and was probably on the proficient to advanced end of the spectrum in terms of editing experience with both, I cringe at claims that one editing style clearly outclasses the other in terms of efficiency, productivity, or whatever. I’d wager that 90% of the time in a keyboard-oriented editor, we navigate by word or line when we’re not navigating by search.
Arguing about editors reminds me of unproductive language disagreements, when we talk in terms of absolutes instead of trade offs.
Agree about 90 claim. After I’ve moved my arrow keys to home row via https://manybutfinite.com/post/home-row-computing/, I became almost as productive at raw text editing anywhere as I was in Emacs or Vim. Well, you also need ace jump and multiple cursors for coding specifically.
I think that some people portray Emacs and Lisp as “holy” and above criticism—although this is certainly a minority of those communities—so others respond with criticism of Emacs’s poor defaults and hostility to new users. People get into heated arguments about their favorite things, and that includes text editors.
It’s mostly team signalling. For some reason a bunch of nerds decided that Emacs/VIM is their Ford/(Holden|Chev) and they need to play silly tribal games.
I would be glad to use emacs as my main editor, but, unfortunately, whenever you need to work with any modern front-end framework the support from emacs is quite basic. But really, I blame frameworks… .jsx and .vue are both a mess as far as syntax parsing goes.
I use emacs for web development, but in my case that’s mostly just HTML and CSS. All the front-end, back-end frameworks always seemed too confusing and appearing/disappearing so quickly, that I loose track of them. Have you used external packages, or as you talking about built-in support?
I use external packages for both, and they do a fine job highlighting syntax but fail short on more “intelligent” features like autocompletion and “go to definition”. Autoformatting is also often hit-or-miss… VSCode is better in this respect, but it’s slower and much less convenient in the actual text editing part, for me at least (maybe I’m just used to emacs and too lazy to configure VSCode properly).
Note that there’s LSP request for this, called selection regions (https://microsoft.github.io/language-server-protocol/specification, can’t link specific request bc toc doesn’t work on mobile).
Make sure that expand region hooks into that, because semantic expand region, coupled with multiple cursors, is the most effective editing feature there is.
What I found most remarkable about this story is that the author actually switched after so many years.
I programmed with notepad - yes, plain Windows notepad - (and later, gedit on Linux) for years. In 2007, I finally took the dive and started vim just because I was changing everything and no longer had the basic thing I used for so long. But like I still use the mouse and arrow keys and such, even with the embracing of the modal editor just because old habits die hard.
Now, after 13 years of vim, I don’t think I could switch to anything again just because I’m so used to it this way. So remarkable the author was able to change!
It’s hard to imagine, but human beings are able to adapt to most things that don’t kill them.
The workflow you describe for Swiper sounds nice. It makes me wish I could try that in VS Code.
Now that I think about it, IntelliJ IDEA’s Find in Path window, which I like a lot, supports the same workflow. Not only does it list your search results (live as you type) in the context of the lines they were in, it also has a second pane that shows your currently-selected result in the context of its file. After typing your search, you can press the Up and Down arrow keys to switch your selected result and instantly preview another one. (You didn’t mention it, but I see that Swiper also previews your selected result, just with a different layout.)