I switched to Kakoune for all my ad-hoc editing although for coding I like to have something more mouse driven for working on multiple files in the same session. I rarely remember the names of source files so I like to have the source tree permanently visible and accessible.
Editors are not a group you can reasonably compare. A JPEG editor and a WAV editor have nothing in common and exactly the same applies to “text” editors. You don’t want to edit HTML and Java and Latex and ToDos and emails in the same way.
If you squint a little you probably would want to edit all programs in the same way but that unfortunately doesn’t work because you just cannot refactor Python like you refactor Java. So even trying to do such a comparison for IDEs is tricky.
All of these discussions about how far away the arrow keys - or your mouse - are, are completely pointless in comparison. This article almost caught on to this fact and gives a list of editors with their strength but doesn’t make it to the conclusion that text editors are just not a reasonable thing to discuss anymore. Nobody edits “text”. And the people who do use Word.
All of these discussions about how far away the arrow keys - or your mouse - are, are completely pointless in comparison. This article almost caught on to this fact and gives a list of editors with their strength but doesn’t make it to the conclusion that text editors are just not a reasonable thing to discuss anymore. Nobody edits “text”. And the people who do use Word.
That’s amusing. Just last night my roommate had a problem where all the cells in her document were set to “£0.00” after saving, it would have taken about 8 hours for her to recover it.
Luckily she already had the list, she just wanted it in a Libreoffice table. I opened vim (Because raw sed is line-based), and just used the expressions: :%s/$/"/, :%s/ \r/, "/. I saved it as a .csv and opened it in Libreoffice Calc, copied the cells, then imported it into Writer by doing C-V and selecting “RTF”.
It took five minutes, not 8 hours. A handful of small adjustments that added 2 minutes on to it, and the table was exactly as before.
You are severely underestimating the power and use of the tools programmers have been using for the last 60 years. The arrogance on display is absolutely staggering.
The purpose of a tool like Vim, is to make your editing commands become muscle memory, so you do not have to think about what you want to do, and then do it. You can simply do it reflexively. I’ve been using it for 8 years on all kinds of information, and it’s extremely powerful.
I wonder, when I hit d} in vim, am I still editing text? The operation itself runs over a paragraph. What about di) which deletes the contents of a set of brackets, do you think you can find a use for that in programming? If your answer here is “paragraphs and argument lists are all text”, that means you’re coming close to the realization that “XML is text”, “S-Expressions are text”, and pretty much every format you can think of is a form of text.
Is ParEdit, a mode for editing the structure of Lisp documents in Emacs, still editing text? What about rope, a refactoring tool for Python with both Emacs and Vim plugins, when you use those plugins, are you still editing text?
Vim provides an interface for “text objects”, which allow you to manipulate XML rather easily, are you editing text, or the objects? Of course you are editing text. Because everything that isn’t a binary format is text.
In addition, both Emacs and Vim have binary editors built in. They both have extensive sets of plugins for editing programming languages while retaining the power of each environment, and the benefit of a uniform interface that you have experience and will log 100s of hours in.
You don’t want to edit HTML and Java and Latex and ToDos and emails in the same way.
You’re right, however, that you don’t want to edit all programs the same way. However, most modern text editors have functionality specific to what you’re editing. Hell, the exact commands used for alphabetically sorting the contents of CSS directives in Vim (:%g/{/ .+1,/}/-1 sort) dates back to before Vim existed – it was a feature of ed(1) – which isn’t even visual!
So, I think your argument is: we are not editing text we are editing all kinds of things in a text representation. Which is also what I was trying to say.
I think we just disagree about the effectiveness of this approach. I agree that the editors we have are often better than nothing but I wouldn’t advertise vim for it’s ability to edit tabular data using :s. Neither do I think the incantation in your last line is something that I should have to know. I just want a CSS editor and then press the sort button.
So, I think your argument is: we are not editing text we are editing all kinds of things in a text representation.
No, my point was that we are all editing text, we just smooth it over so we don’t have to care about the specifics. Text editors do this too, except they provide more power if you wish it. From your comment here and your other comments about this, you seem grossly uneducated about the capabilities of text editors as tools. I’ve linked you articles in another comment – please read them.
I just want a CSS editor and then press the sort button.
You don’t have to know it.
nnoremap <leader> s :%g/{/ .+1,/}/-1 sort
My leader key is set to f. So I can just type f s and the document is sorted. In emacs, I can set a mode switch, so that this keybinding is only available for CSS documents.
You are not expected to know this incantation. It is not a word, it is a sentence. Do you «know» the sentence «Neither do I think the incantation in your last line is something that I should have to know.» ?
The reason we prefer to use a single editor with a language to think about editing in [without agreeing which one] is that things that are just out of reach of the functionality supplied by the editor/plugins/etc. are actually within reach if you express them in the slang of the editor.
Learning such a language probably doesn’t pay off if handling the things typically represented as text is not an activity taking up a large share of your computer use. And maybe not if you just need five representations and the single-use options available for these representations are good enough from your point of view.
But as there are more (and slightly less popular) things to handle, no thanks, I will take a small set of tools I know well and can push one step beyond over sorting through special-case solutions, with many of them missing «trivial» features I have come to depend on.
You don’t want to edit HTML and Java and Latex and ToDos and emails in the same way.
Why not? As an Emacs user, I appreciate that different modes interpret concepts such as paragraphs, words, symbols, top level structures in their own appropriate ways, so that keybindings and other commands trivially adapt to the kind of file I’m working with. Sure, not everything fits perfectly into the abstract, primitive categories, but it’s still preferable to having n different editors and work environments for n different problems.
Because having a dedicated editor is more efficient. PyCharm is better for Python and IntelliJ better for Java and Kile better for Latex and Trello better for Todos and Thunderbird better for Mails.
The reason you can use Emacs reasonably well for all of those is that it actually tries to be n different editors for n different problems. org-mode barely has anything in common with other modes. Paredit as well, etc…
Because having a dedicated editor is more efficient
Having a dedicated editor may be more efficient for a single thing, but most of the projects I work on involve ‘text’ files with at least half a dozen different languages (programming languages, build system scriting, markup languages). If I had to switch between editors for each one then each editor would have to be a lot more efficient to offset the cost of the cognitive load from having different tooling for each file type.
Well I always feel a lot less productive in IntelliJ editors, and find the Emacs equivalents a lot more comfortable. I guess that’s a difference in attitude, but I think it should be considered as a factor.
The reason you can use Emacs reasonably well for all of those is that it actually tries to be n different editors for n different problems
Major modes are interfaces, of sorts, connecting and implementing the files to existing subsystems (completion-at-point, imenu, xref, …), not their own Editors. Sure, some major modes have more additional keybindints, such as Org mode, but it’s not unrelated: I can still use isearch, avy, highlight-symbol-at-point, etc. or any other function that wasn’t written for a specific mode in mind. Paredit is a minor mode for S-Expression based file formats, so I don’t quite get your point here…
Nobody edits “text”. And the people who do use Word.
Thanks for making this point clear. I think programmers (usually systems programmers who post to Lobsters or The Orange Site) have basically boxed themselves into a “fake reality” where talking about plain text email and using vi for prose actually matter. I’m basically the only systems programmer on my team (excluding maybe one or two others), and talking to clients (who almost are all non-technical industries) or even other team members - they have big HTML signatures with images (and use formatting in their messages!), reply on top, use IDEs or maybe Notepad++ on Windows. They don’t tweak their window manager or Emacs config, they’re busy whatever line-of-business application.
I’m not sure that applies to everyone. I have proselint jacked into vim and I use it frequently. The ability to perform operations on sentences or paragraphs without having to move your hand to the mouse is underappreciated.
I had never heard of DOOM Emacs, but as a former Emacs user (but Vim since 2000), I would be quite curious to give it a shot. Also this article has quite a few good Vim plugins that I had not tried yet.
Now the million dollar question, when are we going to see structured editors appear and be used for real?
Doom Emacs is fine. I enjoyed using it as an out of the box experience.
I eventually went back to Vim again with the 8ish plugins I find to be indispensable. I know I sound like an old beardy but there really is value in just knowing what is going on in the editing environment at all times, rather than dealing with oddities where you don’t know what is going on. The author of Doom Emacs is great and responsive on Discord, but it’s just kind of a bummer that you sometimes need to resort to that. That’s part and parcel of the out-of-thx-box experience in non-paid editors as far as I’ve experienced.
I do think that LSPs and coc.nvim has been a huge productivity boost. You’re getting very close to VS Code levels of editor support but with full keyboard navigation.
I’ll crosspost what I wrotw about Doom Emacs on Reddit:
The killer feature of Atom to me is its ability to tell you what commands are associated (or erased) for a keybinding you are pressing, live. It is very practical to debug keybinding issues and I wish more editors had it. Other editors feature similar stuff, but not quite as good as this echo mode for keybinding.
Btw, for Doom Emacs this is accessible through the help interface.
SPC h k <key combo> will open up the manual page for that function, with a description, list of keybindings, argument list, and at the bottom, full code listing where you can jump to references including callers/callees and examine the code in-situ if you need.
SPC h b b will allow you interactive search through Doom Emacs bindings and bring up the same as above, and SPC h b exposes other neat things like keymaps for the current major-mode, etc.
Honestly, I have been using Vim constantly in various forms – GVim, Vim, Vi, ex-vi, Neovim, etc. (Even ex and ed(1) for a little period) for about 8 years. I discovered Doom Emacs this July, and gave it a few hours. Then I kept on giving it a few hours. A week later I hadn’t boot up vim for a week. With Vim, there was always a barrier around writing extensions – it never really felt like it was meant to be integrated with them. The single best Vi experience I’ve had wasn’t with Neovim, it was with ex-vi. There were some sharp edges but the interface felt orders of magnitude more clean than I was used to.
I had tried Emacs before but Spacemacs was poorly integrated – I tried using package-install and I was dumped into a buffer with no evil-mode bindings. And learning Emacs was a hilarious nightmare. Just look at these amazingly terrible commands to know how horrible that was, the last straw was when I tried to undo using C-x u (I think?) and it undid one character at a time!
Two things sold me on Doom Emacs - the support, and the feeling I get when using it.
The support is amazing, I can’t even begin to comprehend how much the maintainer, Henrik, works at it. He has a well-developed system on the discord where you can hit up one of the assigned channels (how-do-i or troubleshooting are the main ones as a newbie), tag @helpme, and you will get seen quickly. He stays up until 2 am some nights answering support requests, and has put a lot of work into doom doctor so there are some rudimentary diagnosics included. It is by far the most pleasant and memorable support experience I’ve ever had with any piece of software in the 10 years I’ve been programming, and I have a huge amount of respect for him.
The feeling I get when using it is harder to quantify. I’ll attempt to quantify the 4 or so years I spent digging into hacker history in the following comparison:
Vim - Editing becomes muscle memory, so you don’t need to think. You can sit down at a computer and be sure it has some variant of Vim that you can use almost like normal.
Emacs - The editor grows around you, as you customize it to your taste. You’re taking an editor built on a language, and altering the code, patching in improvements. Each Emacs instance is totally unique, and can rarely be used by another Emacsen (I actually vaguely recall reading/hearing of a joke where it was implied the Emacs instance and the beard grew into each other).
Doom Emacs, for me at least, is the perfect blend of the muscle memory interface power of Vim, and the “block of clay” feeling I get from Emacs.
Useful article. I’ve picked up a few new vim plugin tips from this (and also learned that I already had vim-commentary installed, I had just forgotten about it and wasn’t using it…). I’m also interested in trying out Doom Emacs - I tried to use spacemacs a while ago but it didn’t really gel with me, but I still dream of being able to have the extensibility of emacs with a vim-like UI.
If the author of this post is in this thread, I am curious if they have tried Amp. It’s a Vim style modal terminal editor with inbuilt support for the sort of abbreviated jumps that they describe using EasyMotion for.
I switched to Kakoune for all my ad-hoc editing although for coding I like to have something more mouse driven for working on multiple files in the same session. I rarely remember the names of source files so I like to have the source tree permanently visible and accessible.
I tried this today based off your comment and I’m pretty impressed with it, esp. as a vi/vim user for the last 25+ years…
Editors are not a group you can reasonably compare. A JPEG editor and a WAV editor have nothing in common and exactly the same applies to “text” editors. You don’t want to edit HTML and Java and Latex and ToDos and emails in the same way.
If you squint a little you probably would want to edit all programs in the same way but that unfortunately doesn’t work because you just cannot refactor Python like you refactor Java. So even trying to do such a comparison for IDEs is tricky.
All of these discussions about how far away the arrow keys - or your mouse - are, are completely pointless in comparison. This article almost caught on to this fact and gives a list of editors with their strength but doesn’t make it to the conclusion that text editors are just not a reasonable thing to discuss anymore. Nobody edits “text”. And the people who do use Word.
That’s amusing. Just last night my roommate had a problem where all the cells in her document were set to “£0.00” after saving, it would have taken about 8 hours for her to recover it.
Luckily she already had the list, she just wanted it in a Libreoffice table. I opened vim (Because raw sed is line-based), and just used the expressions:
:%s/$/"/,:%s/ \r/, "/. I saved it as a .csv and opened it in Libreoffice Calc, copied the cells, then imported it into Writer by doingC-Vand selecting “RTF”.It took five minutes, not 8 hours. A handful of small adjustments that added 2 minutes on to it, and the table was exactly as before.
You are severely underestimating the power and use of the tools programmers have been using for the last 60 years. The arrogance on display is absolutely staggering.
The purpose of a tool like Vim, is to make your editing commands become muscle memory, so you do not have to think about what you want to do, and then do it. You can simply do it reflexively. I’ve been using it for 8 years on all kinds of information, and it’s extremely powerful.
I wonder, when I hit
d}in vim, am I still editing text? The operation itself runs over a paragraph. What aboutdi)which deletes the contents of a set of brackets, do you think you can find a use for that in programming? If your answer here is “paragraphs and argument lists are all text”, that means you’re coming close to the realization that “XML is text”, “S-Expressions are text”, and pretty much every format you can think of is a form of text.Is ParEdit, a mode for editing the structure of Lisp documents in Emacs, still editing text? What about rope, a refactoring tool for Python with both Emacs and Vim plugins, when you use those plugins, are you still editing text? Vim provides an interface for “text objects”, which allow you to manipulate XML rather easily, are you editing text, or the objects? Of course you are editing text. Because everything that isn’t a binary format is text.
In addition, both Emacs and Vim have binary editors built in. They both have extensive sets of plugins for editing programming languages while retaining the power of each environment, and the benefit of a uniform interface that you have experience and will log 100s of hours in.
You’re right, however, that you don’t want to edit all programs the same way. However, most modern text editors have functionality specific to what you’re editing. Hell, the exact commands used for alphabetically sorting the contents of CSS directives in Vim (
:%g/{/ .+1,/}/-1 sort) dates back to before Vim existed – it was a feature ofed(1)– which isn’t even visual!So, I think your argument is: we are not editing text we are editing all kinds of things in a text representation. Which is also what I was trying to say.
I think we just disagree about the effectiveness of this approach. I agree that the editors we have are often better than nothing but I wouldn’t advertise vim for it’s ability to edit tabular data using :s. Neither do I think the incantation in your last line is something that I should have to know. I just want a CSS editor and then press the sort button.
#editorflamewar2020
No, my point was that we are all editing text, we just smooth it over so we don’t have to care about the specifics. Text editors do this too, except they provide more power if you wish it. From your comment here and your other comments about this, you seem grossly uneducated about the capabilities of text editors as tools. I’ve linked you articles in another comment – please read them.
You don’t have to know it.
My leader key is set to
f. So I can just typef sand the document is sorted. In emacs, I can set a mode switch, so that this keybinding is only available for CSS documents.FYI, you can do the same in Vim with ftplugins.
No need for anything complex, just use autocmd
You are not expected to know this incantation. It is not a word, it is a sentence. Do you «know» the sentence «Neither do I think the incantation in your last line is something that I should have to know.» ?
The reason we prefer to use a single editor with a language to think about editing in [without agreeing which one] is that things that are just out of reach of the functionality supplied by the editor/plugins/etc. are actually within reach if you express them in the slang of the editor.
Learning such a language probably doesn’t pay off if handling the things typically represented as text is not an activity taking up a large share of your computer use. And maybe not if you just need five representations and the single-use options available for these representations are good enough from your point of view.
But as there are more (and slightly less popular) things to handle, no thanks, I will take a small set of tools I know well and can push one step beyond over sorting through special-case solutions, with many of them missing «trivial» features I have come to depend on.
Why not? As an Emacs user, I appreciate that different modes interpret concepts such as paragraphs, words, symbols, top level structures in their own appropriate ways, so that keybindings and other commands trivially adapt to the kind of file I’m working with. Sure, not everything fits perfectly into the abstract, primitive categories, but it’s still preferable to having n different editors and work environments for n different problems.
Because having a dedicated editor is more efficient. PyCharm is better for Python and IntelliJ better for Java and Kile better for Latex and Trello better for Todos and Thunderbird better for Mails.
The reason you can use Emacs reasonably well for all of those is that it actually tries to be n different editors for n different problems. org-mode barely has anything in common with other modes. Paredit as well, etc…
Having a dedicated editor may be more efficient for a single thing, but most of the projects I work on involve ‘text’ files with at least half a dozen different languages (programming languages, build system scriting, markup languages). If I had to switch between editors for each one then each editor would have to be a lot more efficient to offset the cost of the cognitive load from having different tooling for each file type.
Well I always feel a lot less productive in IntelliJ editors, and find the Emacs equivalents a lot more comfortable. I guess that’s a difference in attitude, but I think it should be considered as a factor.
Major modes are interfaces, of sorts, connecting and implementing the files to existing subsystems (completion-at-point, imenu, xref, …), not their own Editors. Sure, some major modes have more additional keybindints, such as Org mode, but it’s not unrelated: I can still use isearch, avy,
highlight-symbol-at-point, etc. or any other function that wasn’t written for a specific mode in mind. Paredit is a minor mode for S-Expression based file formats, so I don’t quite get your point here…I most certainly want to do exactly that.
Thanks for making this point clear. I think programmers (usually systems programmers who post to Lobsters or The Orange Site) have basically boxed themselves into a “fake reality” where talking about plain text email and using vi for prose actually matter. I’m basically the only systems programmer on my team (excluding maybe one or two others), and talking to clients (who almost are all non-technical industries) or even other team members - they have big HTML signatures with images (and use formatting in their messages!), reply on top, use IDEs or maybe Notepad++ on Windows. They don’t tweak their window manager or Emacs config, they’re busy whatever line-of-business application.
I’m not sure that applies to everyone. I have proselint jacked into vim and I use it frequently. The ability to perform operations on sentences or paragraphs without having to move your hand to the mouse is underappreciated.
I had never heard of DOOM Emacs, but as a former Emacs user (but Vim since 2000), I would be quite curious to give it a shot. Also this article has quite a few good Vim plugins that I had not tried yet.
Now the million dollar question, when are we going to see structured editors appear and be used for real?
Doom Emacs is fine. I enjoyed using it as an out of the box experience.
I eventually went back to Vim again with the 8ish plugins I find to be indispensable. I know I sound like an old beardy but there really is value in just knowing what is going on in the editing environment at all times, rather than dealing with oddities where you don’t know what is going on. The author of Doom Emacs is great and responsive on Discord, but it’s just kind of a bummer that you sometimes need to resort to that. That’s part and parcel of the out-of-thx-box experience in non-paid editors as far as I’ve experienced.
I do think that LSPs and coc.nvim has been a huge productivity boost. You’re getting very close to VS Code levels of editor support but with full keyboard navigation.
I’ll crosspost what I wrotw about Doom Emacs on Reddit:
Btw, for Doom Emacs this is accessible through the help interface.
SPC h k <key combo>will open up the manual page for that function, with a description, list of keybindings, argument list, and at the bottom, full code listing where you can jump to references including callers/callees and examine the code in-situ if you need.SPC h b bwill allow you interactive search through Doom Emacs bindings and bring up the same as above, andSPC h bexposes other neat things like keymaps for the current major-mode, etc.Honestly, I have been using Vim constantly in various forms – GVim, Vim, Vi, ex-vi, Neovim, etc. (Even ex and ed(1) for a little period) for about 8 years. I discovered Doom Emacs this July, and gave it a few hours. Then I kept on giving it a few hours. A week later I hadn’t boot up vim for a week. With Vim, there was always a barrier around writing extensions – it never really felt like it was meant to be integrated with them. The single best Vi experience I’ve had wasn’t with Neovim, it was with ex-vi. There were some sharp edges but the interface felt orders of magnitude more clean than I was used to.
I had tried Emacs before but Spacemacs was poorly integrated – I tried using package-install and I was dumped into a buffer with no evil-mode bindings. And learning Emacs was a hilarious nightmare. Just look at these amazingly terrible commands to know how horrible that was, the last straw was when I tried to undo using
C-x u(I think?) and it undid one character at a time!Two things sold me on Doom Emacs - the support, and the feeling I get when using it.
doom doctorso there are some rudimentary diagnosics included. It is by far the most pleasant and memorable support experience I’ve ever had with any piece of software in the 10 years I’ve been programming, and I have a huge amount of respect for him.The feeling I get when using it is harder to quantify. I’ll attempt to quantify the 4 or so years I spent digging into hacker history in the following comparison:
Vim - Editing becomes muscle memory, so you don’t need to think. You can sit down at a computer and be sure it has some variant of Vim that you can use almost like normal.
Emacs - The editor grows around you, as you customize it to your taste. You’re taking an editor built on a language, and altering the code, patching in improvements. Each Emacs instance is totally unique, and can rarely be used by another Emacsen (I actually vaguely recall reading/hearing of a joke where it was implied the Emacs instance and the beard grew into each other).
Doom Emacs, for me at least, is the perfect blend of the muscle memory interface power of Vim, and the “block of clay” feeling I get from Emacs.
Useful article. I’ve picked up a few new vim plugin tips from this (and also learned that I already had vim-commentary installed, I had just forgotten about it and wasn’t using it…). I’m also interested in trying out Doom Emacs - I tried to use spacemacs a while ago but it didn’t really gel with me, but I still dream of being able to have the extensibility of emacs with a vim-like UI.
As someone who used vim for a decade and then moved to vscode, I found its vim support to be very adequate.
If the author of this post is in this thread, I am curious if they have tried Amp. It’s a Vim style modal terminal editor with inbuilt support for the sort of abbreviated jumps that they describe using EasyMotion for.
I find it rather peculiar that this guy has been trying out text editors, but does not mention Sublime Text.