Out of all the CLI text editors I've used, I like vi(m) the best. It's powerful, but most importantly for me, it's ubiquitous. But I have to call a spade a spade: vi's UX is atrocious. Probably...
Out of all the CLI text editors I've used, I like vi(m) the best. It's powerful, but most importantly for me, it's ubiquitous.
But I have to call a spade a spade: vi's UX is atrocious. Probably because it was written before "UX" was even conceived of. Commands are arcane and proprietary, feature discoverability is basically zero. If you want to be any good at using it, be prepared to pore over docs and cheatsheets and get ready to memorize a ton of nonsensical incantations. Yes, it does have its own internally consistent vocabulary but it doesn't really have anything in common with other software or UI conventions.
I'd love to try a CLI editor designed with modern sensibilities but unless there's a way to get it installed on every random server I SSH to, there's not really any point for me. For local work, as far as I'm concerned, there's no substitute for an application with a good GUI.
The ubiquity is what I love. It certainly seems arcane, and you are absolutely correct - there is little to no discoverability. I think you've hit on a really important topic though; things that...
The ubiquity is what I love. It certainly seems arcane, and you are absolutely correct - there is little to no discoverability. I think you've hit on a really important topic though; things that are sufficiently powerful have a learning curve. I think it's okay that things have a learning curve, and I think that it's important to note that vi is absolutely not an editor for everyone. I would never recommend it for someone who isn't a sysadmin or developer.
It's OK for software to have a learning curve, but it should be designed with discoverability patterns so that said learning curve doesn't feel insurmountable. Any software should be usable out of...
It's OK for software to have a learning curve, but it should be designed with discoverability patterns so that said learning curve doesn't feel insurmountable. Any software should be usable out of the box for at least some of its basic designed tasks without needing to consult a manual.
In all seriousness and without any kind of facetiousness, this is manifested in the manual. "RTFM" may be uttered brusquely and rudely, but most editors in the vi family (especially vim) have...
discoverability patterns
In all seriousness and without any kind of facetiousness, this is manifested in the manual. "RTFM" may be uttered brusquely and rudely, but most editors in the vi family (especially vim) have fantastic documentation.
Most software is easy to learn without needing a manual. Reading the manual should be for learning how to use more advanced functionality. There is far more complicated software out there than Vim...
Most software is easy to learn without needing a manual. Reading the manual should be for learning how to use more advanced functionality. There is far more complicated software out there than Vim that doesn't need a manual to figure out how to get basic work done.
Most software is written for point-and-click user interfaces where discoverability is fairly simple. And as such, most software tends to be fairly limited in its capabilities. As commented...
Most software is written for point-and-click user interfaces where discoverability is fairly simple. And as such, most software tends to be fairly limited in its capabilities. As commented elsewhere in this thread, vi/vim are fully programmable (nvi, an older variant of vi, is extensible with LISP!).
If you're coming at vim with the expectations of someone who grew up on Windows, you're going to have a bad time. vim's expectations of the user are different. I won't comment on whether they're better, as down that path is an editor war, but I will say that they are different.
Just a nitpick, but I believe the word you were looking for was arbitrary. Honestly, that's what I find funny about the "editor wars". People argue about which 40+ year old text editor is better...
Commands are arcane and proprietary ...
Just a nitpick, but I believe the word you were looking for was arbitrary.
For local work, as far as I'm concerned, there's no substitute for an application with a good GUI.
Honestly, that's what I find funny about the "editor wars". People argue about which 40+ year old text editor is better when practically every editor offers the same functions, either natively or with extensions. The thing that really gets me is that the kinds of people to care about the extra 'efficiency' of emacs or vi keybindings are usually coders of some sort, but it's really people who are typing in long streams who would benefit the most from those features. Coding is usually stop and go with frequent pauses for research.
Ubiquity is the best argument for Vi, I feel, but it's one that is becoming less and less important as time goes on since devops seems to be trending away from systems that require you to log into a server's console.
I'm a coder and I made a concerted effort to learn Vim for a few weeks. I did not feel like it would actually make me faster or more productive. The small time savings from the memorized keyboard...
I'm a coder and I made a concerted effort to learn Vim for a few weeks.
I did not feel like it would actually make me faster or more productive. The small time savings from the memorized keyboard commands aren't significant enough to mean much compared to what I can already do in GUI text editors like Sublime and Visual Studio. It seemed like a whole lot of upfront effort for maybe a 1-2% overall improvement.
Yeah. You're not going to get much benefit from learning vi if you're suffering from Windows. The metaphors and paradigms are all. over. on Unix, though. Everything from document pagers to RPGs...
Visual Studio
whole lot of upfront effort for maybe a 1-2% overall improvement.
Yeah. You're not going to get much benefit from learning vi if you're suffering from Windows.
The metaphors and paradigms are all. over. on Unix, though. Everything from document pagers to RPGs use those keybindings and metaphors.
I was learning vim for over a month and I can say, that while I use it while SSHing or editing config files, I’d never use it as IDE. When programming, VS Code is just superiour, easier and more...
I was learning vim for over a month and I can say, that while I use it while SSHing or editing config files, I’d never use it as IDE. When programming, VS Code is just superiour, easier and more effective - because it was designed to be IDE.
The thing where vim shines, is editing text.
I had a class of about 200 properties, some of which were nested into other ones. I had to rewrite the class into scriptable format (with all the properties, data types and hiearchy being easy to parse by other developer). This would take me at least half an hour, and probably more by doing it by hand, with risk of typos and inconsistencies. But I just opened vim, defined like 4 or 5 macros (great thing, learn about it), and in less than 10 minutes, I was done.
This is why I love vim. Mostly I don’t use it’s full power and it would be faster to use some normal gui editor. But when I do truly need it, it’s awesome.
I meant proprietary in the sense that vi's commands are non-standard, the program's vocabulary isn't really shared with any other programs or common conventions. On consulting with a dictionary,...
I believe the word you were looking for was arbitrary.
I meant proprietary in the sense that vi's commands are non-standard, the program's vocabulary isn't really shared with any other programs or common conventions. On consulting with a dictionary, it looks like that word doesn't mean what I think it means.
Anyway, yes, they're certainly arbitrary too. Though I get initialisms like w for "write" and y for "yank", it's confounding when the rest of the world uses "save" and "copy" to describe the same actions.
On the contrary, vi is included in the Single Unix Specification (see here for an updated version, developed in tandem with IEEE) by The Open Group (the organization behind POSIX and who controls...
vi's commands are non-standard
On the contrary, vi is included in the Single Unix Specification (see here for an updated version, developed in tandem with IEEE) by The Open Group (the organization behind POSIX and who controls the name Unix). Short of being included in an ISO standard, this is about as standard as you can get. Beyond that, the metaphors, paradigms, and keybindings are everywhere on Unix. It is both a literal and a de facto standard. It is ingrained in the culture of Unix in a way few other tools are.
It really does seem like you meant arbitrary like Akir said.
It is not the same features tho. Vim and especially Emacs can be extended to do anything, and with Emacs you can wire anything into everything. IDK of any modern "editor" with that feature set,...
It is not the same features tho. Vim and especially Emacs can be extended to do anything, and with Emacs you can wire anything into everything. IDK of any modern "editor" with that feature set, similar breadth and depth of possibilites, and a community that outputs similarly great stuff (org mode, elfeed, magit, to name a few I use regularly). Emacs is less efficient than vi, and even ST or VSC for some editing tasks, but it offers so much more goodies that anything out there.
I see the editor war as more of an argument amongst people who are passionate about their tools (editors are tools for coders after all). This is more so when you've spent a considerable time...
People argue about which 40+ year old text editor is better when practically every editor offers the same functions, either natively or with extensions.
I see the editor war as more of an argument amongst people who are passionate about their tools (editors are tools for coders after all). This is more so when you've spent a considerable time customizing that tool to your needs (I have been tweaking my emacs config for close to 10 years now)
I also disagree about emacs (or vi) keybindings not providing any significant efficiency improvement. Apart from "stop and go" typing, A lot of coding is also text manipulation (refactoring code, moving code around, etc) and moving around in your source files (jumping to the next fn def, etc). Having keybindings tailored to your needs (and the language you're working in) does improve your efficiency. (This is even more important when working with a lisp based language, I cannot imagine not using emacs when working with CL or clojure).
(Also, typing long streams of text would amount to same (similar?) amount of keystrokes irrespective of the editor used, however the amount of keystrokes could considerably be different when you're moving around a file, based on the keybindings the editor provides)
For local work, as far as I'm concerned, there's no substitute for an application with a good GUI.
Also why is a graphical user interface important for a text editor? As long as the application in question has a good user interface, why does it matter if it graphical or not? I would rather have a text editor that works well over SSH or if I am running it from XWindows (a la emacs), ... or even allow me to edit files over SSH.
I guess at the end of the day I am just tired of all these editor wars. Use the tool(editor) that works for you. However, before passing judgment on another user's choice of tools, try out those tools in earnest! (These tools have a steep learning curve, and trying out vim/emacs over an afternoon isn't really going to expose you to the advantages people glean from using them)
Also, there should be a reason why emacs is still being actively developed and maintained with an active base of users developing packages in elisp for it! And you have projects like neovim...
I have been using vim for about 2 years now. I still feel like I do not know much more than the surface level stuff when I am editing text. Does anyone have any tips for learning vim at a "deeper"...
I have been using vim for about 2 years now. I still feel like I do not know much more than the surface level stuff when I am editing text. Does anyone have any tips for learning vim at a "deeper" level.
Try vimtutor included in Vim, and then read this: https://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118 That SO answer is simply great. The...
That SO answer is simply great. The best thing about Vim is that it is "Vi, iMproved", and the "vi" part is just as important and useful as the "iMproved" part.
I’ve used vi(m) for going on ten years now in some capacity and still have to look up about 90% of the things I want to do outside of simple text entry.
I’ve used vi(m) for going on ten years now in some capacity and still have to look up about 90% of the things I want to do outside of simple text entry.
I think the problem is half committing. It's literally like learning a new language, if you only practice with your cousins you see once a month, it's probably never going to happen. I used it for...
I think the problem is half committing. It's literally like learning a new language, if you only practice with your cousins you see once a month, it's probably never going to happen. I used it for work full time and it took about 6 months to become reasonably comfortable with it, but it's been 8 years now and I'm still learning more efficient ways of doing things.
Agreed. It takes active engagement to learn new commands in vim. You start with something like vimtutor, then read the manual, testing commands as you go. Then, you need to practice, which means...
Agreed. It takes active engagement to learn new commands in vim. You start with something like vimtutor, then read the manual, testing commands as you go. Then, you need to practice, which means you need to recognize editing patterns that could potentially be commands, look them up, and then use them. regularly.
Something that I never see talked about with Vim, and one of the things I like about it, is that it makes editing fun. I like to hope it makes me more productive, but wouldn't be surprised to find...
Something that I never see talked about with Vim, and one of the things I like about it, is that it makes editing fun.
I like to hope it makes me more productive, but wouldn't be surprised to find out any perceived productivity gain is just that - perceived. But for me, Vim makes basic and complex editing tasks fun. Moving around and getting the cursor to go where I want without touching a mouse feels like a superpower. Figuring out how to string together commands to achieve a goal is like solving a puzzle. Watching a macro run on every line in sequence is like toppling dominoes.
It just feels good to use Vim. I'm at the point where a lot of it is muscle memory, so my conscious mind gets to watch as my body convinces my computer to do exactly what I need. A mind-reading text editor is pretty fun to use, it turns out!
Sure, I could probably accomplish these tasks in another editor, possibly even faster than in Vim. But I wouldn't enjoy the editing process nearly as much.
I think the problem is that this list is meant to show the power of vim, which means a varied list of usage examples. In the real world, no one would be memorizing each of these examples. The list...
I think the problem is that this list is meant to show the power of vim, which means a varied list of usage examples. In the real world, no one would be memorizing each of these examples. The list is constructed from primitive commands (that would be memorized) that combine to show the power of vim to do useful things that other editors likely can't do (ie: applying a regex to a selection of lines or emailing a paragraph).
I'm not a vim super user by any means but one thing I've found incredibly useful time and time again is recording actions with q. Then replaying them with @. I like it because you don't need to...
I'm not a vim super user by any means but one thing I've found incredibly useful time and time again is recording actions with q. Then replaying them with @. I like it because you don't need to know the "correct" way to preform an edit, as long as it's generic enough you'll be able to reuse it. It's saved me a ton of time when, for example, refactoring a block of function calls to use different parameters.
These features are generic (not sure if all of them, didn't read all) in the sense that they are also available when you're editing text. When typing text, you don't really recognise the need for...
These features are generic (not sure if all of them, didn't read all) in the sense that they are also available when you're editing text. When typing text, you don't really recognise the need for it all that much (tho, even as an Emacser---and I don't use evil---, I always miss vi style navigation), but when editing, vi's navigation comes in handy.
It is not something you learn wholesale. You don't need most of this to begin using vi(m) with the same efficiency as other text editors. IDE-like features can easily be plugged selectively, especially to Vim (IDK much about neovim). All you need to know to start using it is that it starts in normal mode, i goes into insert mode (where you can type text), and ESC takes you back to normal where you can use all the navigation commands. hjkl navigation is a nice thing to learn too. From there on, you learn stuff as you need them, as you read the docs looking for specific things, or as you see others use them.
You can use vimtutor (run the vimtutor program in your terminal) which is an interactive guide to the most basic commands. Then read the StackOverflow answer I linked elsewhere in the thread. All in all, a couple days worth of preparation gets it going.
Is it worth it? If you do lots of manual edits to text, then yes. If I compare typing/editing prose on say LibreOffice, any usual text editor, Emacs, and Vi(m), the latter two are far more better than the former two. Emacs is not as good as Vi (tho there is the Evil package), but still, it is just better than anything else unless it is Vi(m) or it has some sort of good Vi or Emacs bindings emulation. And the thing that's so much better is that the range of different types of motion and editing commands is so much bigger. Any amount of any motion or editing command is a few keys away, but with more "normal" editors, you're limited to arrow keys that move around letter by letter, Ctrl + arrow keys that go word by word, Shift + (Ctrl) + arrow keys that can select, and that's it. Either repeat these or use the mouse. That's inefficient when you need to do that so many times.
Yeah, I'm in vim all day every day, and I've never seen lots of this. All this stuff about marking lines? Gimme visual mode every day, just shift-v to mark entire lines, and you've got a visual...
Yeah, I'm in vim all day every day, and I've never seen lots of this. All this stuff about marking lines? Gimme visual mode every day, just shift-v to mark entire lines, and you've got a visual representation of exactly the text that will be affected by your next action. > to indent or < to dedent are some useful commands I didn't see listed here (double-stroke to affect the current line rather than a selection).
Out of all the CLI text editors I've used, I like vi(m) the best. It's powerful, but most importantly for me, it's ubiquitous.
But I have to call a spade a spade: vi's UX is atrocious. Probably because it was written before "UX" was even conceived of. Commands are arcane and proprietary, feature discoverability is basically zero. If you want to be any good at using it, be prepared to pore over docs and cheatsheets and get ready to memorize a ton of nonsensical incantations. Yes, it does have its own internally consistent vocabulary but it doesn't really have anything in common with other software or UI conventions.
I'd love to try a CLI editor designed with modern sensibilities but unless there's a way to get it installed on every random server I SSH to, there's not really any point for me. For local work, as far as I'm concerned, there's no substitute for an application with a good GUI.
The ubiquity is what I love. It certainly seems arcane, and you are absolutely correct - there is little to no discoverability. I think you've hit on a really important topic though; things that are sufficiently powerful have a learning curve. I think it's okay that things have a learning curve, and I think that it's important to note that vi is absolutely not an editor for everyone. I would never recommend it for someone who isn't a sysadmin or developer.
It's OK for software to have a learning curve, but it should be designed with discoverability patterns so that said learning curve doesn't feel insurmountable. Any software should be usable out of the box for at least some of its basic designed tasks without needing to consult a manual.
In all seriousness and without any kind of facetiousness, this is manifested in the manual. "RTFM" may be uttered brusquely and rudely, but most editors in the vi family (especially vim) have fantastic documentation.
Most software is easy to learn without needing a manual. Reading the manual should be for learning how to use more advanced functionality. There is far more complicated software out there than Vim that doesn't need a manual to figure out how to get basic work done.
Most software is written for point-and-click user interfaces where discoverability is fairly simple. And as such, most software tends to be fairly limited in its capabilities. As commented elsewhere in this thread, vi/vim are fully programmable (nvi, an older variant of vi, is extensible with LISP!).
If you're coming at vim with the expectations of someone who grew up on Windows, you're going to have a bad time. vim's expectations of the user are different. I won't comment on whether they're better, as down that path is an editor war, but I will say that they are different.
Just a nitpick, but I believe the word you were looking for was arbitrary.
Honestly, that's what I find funny about the "editor wars". People argue about which 40+ year old text editor is better when practically every editor offers the same functions, either natively or with extensions. The thing that really gets me is that the kinds of people to care about the extra 'efficiency' of emacs or vi keybindings are usually coders of some sort, but it's really people who are typing in long streams who would benefit the most from those features. Coding is usually stop and go with frequent pauses for research.
Ubiquity is the best argument for Vi, I feel, but it's one that is becoming less and less important as time goes on since devops seems to be trending away from systems that require you to log into a server's console.
I'm a coder and I made a concerted effort to learn Vim for a few weeks.
I did not feel like it would actually make me faster or more productive. The small time savings from the memorized keyboard commands aren't significant enough to mean much compared to what I can already do in GUI text editors like Sublime and Visual Studio. It seemed like a whole lot of upfront effort for maybe a 1-2% overall improvement.
Yeah. You're not going to get much benefit from learning vi if you're suffering from Windows.
The metaphors and paradigms are all. over. on Unix, though. Everything from document pagers to RPGs use those keybindings and metaphors.
I learned vi-keys first from playing Nethack, and only much later started to use them for editing text (and that in Emacs more often than vi/vim!)
I was learning vim for over a month and I can say, that while I use it while SSHing or editing config files, I’d never use it as IDE. When programming, VS Code is just superiour, easier and more effective - because it was designed to be IDE.
The thing where vim shines, is editing text.
I had a class of about 200 properties, some of which were nested into other ones. I had to rewrite the class into scriptable format (with all the properties, data types and hiearchy being easy to parse by other developer). This would take me at least half an hour, and probably more by doing it by hand, with risk of typos and inconsistencies. But I just opened vim, defined like 4 or 5 macros (great thing, learn about it), and in less than 10 minutes, I was done.
This is why I love vim. Mostly I don’t use it’s full power and it would be faster to use some normal gui editor. But when I do truly need it, it’s awesome.
I meant proprietary in the sense that vi's commands are non-standard, the program's vocabulary isn't really shared with any other programs or common conventions. On consulting with a dictionary, it looks like that word doesn't mean what I think it means.
Anyway, yes, they're certainly arbitrary too. Though I get initialisms like
wfor "write" andyfor "yank", it's confounding when the rest of the world uses "save" and "copy" to describe the same actions.On the contrary, vi is included in the Single Unix Specification (see here for an updated version, developed in tandem with IEEE) by The Open Group (the organization behind POSIX and who controls the name Unix). Short of being included in an ISO standard, this is about as standard as you can get. Beyond that, the metaphors, paradigms, and keybindings are everywhere on Unix. It is both a literal and a de facto standard. It is ingrained in the culture of Unix in a way few other tools are.
It really does seem like you meant arbitrary like Akir said.
It is not the same features tho. Vim and especially Emacs can be extended to do anything, and with Emacs you can wire anything into everything. IDK of any modern "editor" with that feature set, similar breadth and depth of possibilites, and a community that outputs similarly great stuff (org mode, elfeed, magit, to name a few I use regularly). Emacs is less efficient than vi, and even ST or VSC for some editing tasks, but it offers so much more goodies that anything out there.
I see the editor war as more of an argument amongst people who are passionate about their tools (editors are tools for coders after all). This is more so when you've spent a considerable time customizing that tool to your needs (I have been tweaking my emacs config for close to 10 years now)
I also disagree about emacs (or vi) keybindings not providing any significant efficiency improvement. Apart from "stop and go" typing, A lot of coding is also text manipulation (refactoring code, moving code around, etc) and moving around in your source files (jumping to the next fn def, etc). Having keybindings tailored to your needs (and the language you're working in) does improve your efficiency. (This is even more important when working with a lisp based language, I cannot imagine not using emacs when working with CL or clojure).
(Also, typing long streams of text would amount to same (similar?) amount of keystrokes irrespective of the editor used, however the amount of keystrokes could considerably be different when you're moving around a file, based on the keybindings the editor provides)
Also why is a graphical user interface important for a text editor? As long as the application in question has a good user interface, why does it matter if it graphical or not? I would rather have a text editor that works well over SSH or if I am running it from XWindows (a la emacs), ... or even allow me to edit files over SSH.
I guess at the end of the day I am just tired of all these editor wars. Use the tool(editor) that works for you. However, before passing judgment on another user's choice of tools, try out those tools in earnest! (These tools have a steep learning curve, and trying out vim/emacs over an afternoon isn't really going to expose you to the advantages people glean from using them)
Also, there should be a reason why emacs is still being actively developed and maintained with an active base of users developing packages in elisp for it! And you have projects like neovim...
I have been using vim for about 2 years now. I still feel like I do not know much more than the surface level stuff when I am editing text. Does anyone have any tips for learning vim at a "deeper" level.
You might want to have a look at "Practical Vim: Edit Text at the Speed of Thought"
https://pragprog.com/book/dnvim2/practical-vim-second-edition
Try vimtutor included in Vim, and then read this: https://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118
That SO answer is simply great. The best thing about Vim is that it is "Vi, iMproved", and the "vi" part is just as important and useful as the "iMproved" part.
I’ve used vi(m) for going on ten years now in some capacity and still have to look up about 90% of the things I want to do outside of simple text entry.
I think the problem is half committing. It's literally like learning a new language, if you only practice with your cousins you see once a month, it's probably never going to happen. I used it for work full time and it took about 6 months to become reasonably comfortable with it, but it's been 8 years now and I'm still learning more efficient ways of doing things.
Agreed. It takes active engagement to learn new commands in vim. You start with something like vimtutor, then read the manual, testing commands as you go. Then, you need to practice, which means you need to recognize editing patterns that could potentially be commands, look them up, and then use them. regularly.
Something that I never see talked about with Vim, and one of the things I like about it, is that it makes editing fun.
I like to hope it makes me more productive, but wouldn't be surprised to find out any perceived productivity gain is just that - perceived. But for me, Vim makes basic and complex editing tasks fun. Moving around and getting the cursor to go where I want without touching a mouse feels like a superpower. Figuring out how to string together commands to achieve a goal is like solving a puzzle. Watching a macro run on every line in sequence is like toppling dominoes.
It just feels good to use Vim. I'm at the point where a lot of it is muscle memory, so my conscious mind gets to watch as my body convinces my computer to do exactly what I need. A mind-reading text editor is pretty fun to use, it turns out!
Sure, I could probably accomplish these tasks in another editor, possibly even faster than in Vim. But I wouldn't enjoy the editing process nearly as much.
I think the problem is that this list is meant to show the power of vim, which means a varied list of usage examples. In the real world, no one would be memorizing each of these examples. The list is constructed from primitive commands (that would be memorized) that combine to show the power of vim to do useful things that other editors likely can't do (ie: applying a regex to a selection of lines or emailing a paragraph).
I'm not a vim super user by any means but one thing I've found incredibly useful time and time again is recording actions with
q. Then replaying them with@. I like it because you don't need to know the "correct" way to preform an edit, as long as it's generic enough you'll be able to reuse it. It's saved me a ton of time when, for example, refactoring a block of function calls to use different parameters.These features are generic (not sure if all of them, didn't read all) in the sense that they are also available when you're editing text. When typing text, you don't really recognise the need for it all that much (tho, even as an Emacser---and I don't use evil---, I always miss vi style navigation), but when editing, vi's navigation comes in handy.
It is not something you learn wholesale. You don't need most of this to begin using vi(m) with the same efficiency as other text editors. IDE-like features can easily be plugged selectively, especially to Vim (IDK much about neovim). All you need to know to start using it is that it starts in
normalmode,igoes intoinsertmode (where you can type text), andESCtakes you back tonormalwhere you can use all the navigation commands.hjklnavigation is a nice thing to learn too. From there on, you learn stuff as you need them, as you read the docs looking for specific things, or as you see others use them.You can use vimtutor (run the
vimtutorprogram in your terminal) which is an interactive guide to the most basic commands. Then read the StackOverflow answer I linked elsewhere in the thread. All in all, a couple days worth of preparation gets it going.Is it worth it? If you do lots of manual edits to text, then yes. If I compare typing/editing prose on say LibreOffice, any usual text editor, Emacs, and Vi(m), the latter two are far more better than the former two. Emacs is not as good as Vi (tho there is the Evil package), but still, it is just better than anything else unless it is Vi(m) or it has some sort of good Vi or Emacs bindings emulation. And the thing that's so much better is that the range of different types of motion and editing commands is so much bigger. Any amount of any motion or editing command is a few keys away, but with more "normal" editors, you're limited to arrow keys that move around letter by letter,
Ctrl+ arrow keys that go word by word,Shift+ (Ctrl) + arrow keys that can select, and that's it. Either repeat these or use the mouse. That's inefficient when you need to do that so many times.Yeah, I'm in vim all day every day, and I've never seen lots of this. All this stuff about marking lines? Gimme visual mode every day, just shift-v to mark entire lines, and you've got a visual representation of exactly the text that will be affected by your next action. > to indent or < to dedent are some useful commands I didn't see listed here (double-stroke to affect the current line rather than a selection).
I use vi(m) when necessary, but in my computers i'm using kakoune. It's similar, but slightly different.
The instant feedback helps a lot.