Why don’t we have good code editors?(kristofer.reykjal.in)
kristofer.reykjal.in
Why don’t we have good code editors?
https://kristofer.reykjal.in/2019/09/27/its-2019-why-dont-we-have-good-code-editors/
73 comments
> I know how to get to any line in any file with less than 3 keystrokes
FWIW it is 2 key strokes in VSCode (ctrl-g, then the line number or -n to index back from the end of the file) out of the box. Ctrl-p takes you to any fuzzy-matched file in your workspace.
My point is that VSCode has a lot of shortcuts too - you don't need to use the mouse if you really do need those extra couple of seconds time savings in your 8 hour work day in order to meet your deadlines. But on the plus side you can use they keyboard or the mouse as you see fit - best of both worlds.
If you really are working in such a sweatshop where saving a couple of seconds a day is something you need to think about, then you have my pitty and condolences! At least for me, not every single waking second of my work day is spent hammering out code - I am probably only actively typing in new code perhaps 20-25% of the time max with the rest going on reading existing code, stepping through a debugger, dealing with tickets/bugs, running tests, doing emails, meetings etc etc.
For me, something like VSCode offers some nice visual benefits, e.g. the minimap is super useful, subtle indentation lines, line-length rulers, intellisense popups near where I am actually looking, spelling squigglies etc. I would not be surprised to learn that vi/Emacs can do the same, but if you are adding all that to a text mode editor, why bother and not just use a modern visual editor and just be done with it? Just muscle memory?
FWIW it is 2 key strokes in VSCode (ctrl-g, then the line number or -n to index back from the end of the file) out of the box. Ctrl-p takes you to any fuzzy-matched file in your workspace.
My point is that VSCode has a lot of shortcuts too - you don't need to use the mouse if you really do need those extra couple of seconds time savings in your 8 hour work day in order to meet your deadlines. But on the plus side you can use they keyboard or the mouse as you see fit - best of both worlds.
If you really are working in such a sweatshop where saving a couple of seconds a day is something you need to think about, then you have my pitty and condolences! At least for me, not every single waking second of my work day is spent hammering out code - I am probably only actively typing in new code perhaps 20-25% of the time max with the rest going on reading existing code, stepping through a debugger, dealing with tickets/bugs, running tests, doing emails, meetings etc etc.
For me, something like VSCode offers some nice visual benefits, e.g. the minimap is super useful, subtle indentation lines, line-length rulers, intellisense popups near where I am actually looking, spelling squigglies etc. I would not be surprised to learn that vi/Emacs can do the same, but if you are adding all that to a text mode editor, why bother and not just use a modern visual editor and just be done with it? Just muscle memory?
> If you really are working in such a sweatshop where saving a couple of seconds a day is something you need to think about, then you have my pitty and condolences! At least for me, not every single waking second of my work day is spent hammering out code - I am probably only actively typing in new code perhaps 20-25% of the time max with the rest going on reading existing code, stepping through a debugger, dealing with tickets/bugs, running tests, doing emails, meetings etc etc.
The reason to not having to move your fingers/arms much is not about time. You just stay in the zone longer, you have less possibilities of distractions... It is about comfort and not disturbing the flow.
It's the same with music (wether is jazz or blues at least). Good intrumentists just don't move their hands much, lest their instrument goes in the way of their improvisation. 60% of the time, our job is quite boring, so make sure you really enjoy the 40% that's left.
The reason to not having to move your fingers/arms much is not about time. You just stay in the zone longer, you have less possibilities of distractions... It is about comfort and not disturbing the flow.
It's the same with music (wether is jazz or blues at least). Good intrumentists just don't move their hands much, lest their instrument goes in the way of their improvisation. 60% of the time, our job is quite boring, so make sure you really enjoy the 40% that's left.
> the minimap is super useful
Is that really something you use all the time? I tried to switch from emacs to vscode in 2017, but in practice the minimap didn't do that much for me. Nor did the graphical file view to the left. The emacs experience is just too fast and good, even though it means I need to carry my customizations with me everywhere to get those intellisense popups and spelling squigglies.
Is that really something you use all the time? I tried to switch from emacs to vscode in 2017, but in practice the minimap didn't do that much for me. Nor did the graphical file view to the left. The emacs experience is just too fast and good, even though it means I need to carry my customizations with me everywhere to get those intellisense popups and spelling squigglies.
Yeah I use it all the time - seeing the "shape" of the code is great for jumping around quickly when you don't know the line numbers and it is quicker to look + click once then to find a string in the file instead.
VSCode is fast - certainly as fast as my brain. Atom was crap IME but MS have done a really good job regarding performance for VSCode. Start-up time is a bit slow, but you only do that once when you reboot every few days/weeks/months
VSCode is fast - certainly as fast as my brain. Atom was crap IME but MS have done a really good job regarding performance for VSCode. Start-up time is a bit slow, but you only do that once when you reboot every few days/weeks/months
If finding a string involves popping up a modal dialog I can understand navigating by the minimap. Finding a string in emacs is really fast - Ctrl-S, start typing the string, and you're there before you know it. The minibuffer is way better for this kind of interaction than a modal dialog is.
In VSCode there is no modal - ctrl-f then type (regex is supported) and it autoscrolls + highlights in the text, the minimap, and the scrollbar. No mouse (unless you want to) - you don't even need to press enter.
So apart from lacking the visual feedback of scrollbars etc, sounds like emacs is the same.
So apart from lacking the visual feedback of scrollbars etc, sounds like emacs is the same.
I use the minimap (in Atom, not VS Code) to quickly see touched lines for git purposes, locate errors I know exist due to changes elsewhere, quickly find merge conflict blocks, see search matches at a glance, etc. It can do quite a lot.
The mouse is not a "clumsy" input and there are plenty of situations in which the mouse allows more efficient usage than the keyboard like when navigating through 2D space. For example it is clearly more efficient to place your cursor at a certain arbitrary point in the document using the mouse than to navigate there using keyboard commands.
I'm also not really convinced about the "hands on the keyboard" argument... What percentage of the time that you work are your hands actually on the keyboard and ready to input? Are they on the keyboard right now? Because that seems like an uncomfortable way to sit at a workstation. I also don't think it takes very much time to switch between the input devices unless maybe you don't have practice with that workflow.
I'm also not really convinced about the "hands on the keyboard" argument... What percentage of the time that you work are your hands actually on the keyboard and ready to input? Are they on the keyboard right now? Because that seems like an uncomfortable way to sit at a workstation. I also don't think it takes very much time to switch between the input devices unless maybe you don't have practice with that workflow.
> The mouse is not a "clumsy" input and there are plenty of situations in which the mouse allows more efficient usage than the keyboard like when navigating through 2D space. For example it is clearly more efficient to place your cursor at a certain arbitrary point in the document using the mouse than to navigate there using keyboard commands.
Have you ever used emacs? If not theres a mode called ace-jump, which I'm pretty sure beats every interaction with a mouse to get to a certain point within a document. I'd wager that, if we'd start at the same time, I'd be at that point before you actually touch the mouse with the hand that you just lifted. Honestly, it's worth checking out. There is a lot of things that emacs and vim are brilliant at, they had tens of years to figure things out after all...
Have you ever used emacs? If not theres a mode called ace-jump, which I'm pretty sure beats every interaction with a mouse to get to a certain point within a document. I'd wager that, if we'd start at the same time, I'd be at that point before you actually touch the mouse with the hand that you just lifted. Honestly, it's worth checking out. There is a lot of things that emacs and vim are brilliant at, they had tens of years to figure things out after all...
There have been numerous studies on this, and the results are basically always: people don’t think that it’s faster to stick with the keyboard, but it is. Yes, even for people who are very familiar with the task, the keyboards, and the mice.
There are some interactions where switching to the mouse and back is faster; things like drawing and navigation through irregular shapes (I.e. “not grids or lists”).
Whether that difference is important to you or not is far more about your specific circumstances than anything else. Comfort is important also.
There are some interactions where switching to the mouse and back is faster; things like drawing and navigation through irregular shapes (I.e. “not grids or lists”).
Whether that difference is important to you or not is far more about your specific circumstances than anything else. Comfort is important also.
> Are they on the keyboard right now?
Of course they're not on the keyboard while I'm exclusively reading. But while I'm in vim, my hands certainly are on the keyboard nearly at all times, resting on the home row.
Of course they're not on the keyboard while I'm exclusively reading. But while I'm in vim, my hands certainly are on the keyboard nearly at all times, resting on the home row.
When I’m trying to understand code, my hands are absolutely on the keyboard. This is very common and quite efficient once you learn how to navigate using a code editor.
This is similar to the way a mathematician will often ‘read’ math with a pencil and paper, or a musician will ‘read’ music with an instrument in hand.
When I’m reading prose, I often don’t have either a keyboard or a mouse, but that’s a very different operation (uses different parts of the brain, etc).
This is similar to the way a mathematician will often ‘read’ math with a pencil and paper, or a musician will ‘read’ music with an instrument in hand.
When I’m reading prose, I often don’t have either a keyboard or a mouse, but that’s a very different operation (uses different parts of the brain, etc).
I guess we can't all be 10x geniuses who have their codebase memorized. It's really not crazy to want to take advantage of modern UI, and the idea that you simply don't need to see a file tree is nonsense.
I never said memorized. I do believe if you truly understand your code however (and ours spans 500k+) then you don't need a file browser to know that components live in the "components" folder.
I agree with taking advantage of a modern UI, all programs could benefit from advancements. I find the article was written with little research or thought put into what is available on the terminal.
I agree with taking advantage of a modern UI, all programs could benefit from advancements. I find the article was written with little research or thought put into what is available on the terminal.
You do have to memorize a ton of arcane key strokes just to get around in your editor though. I bet that time invested is a big reason why some coders hang onto terminal editors.
IMO you shouldn't have to do "research" to setup your editor or even simply to use it effectively. With VS Code everything that you need is already integrated and clearly stated - Ctrl+Shift+P to find any command Ctrl+P to open any file in your workspace (no file browser needed). When you want to expand - you have the integrated Extensions marketplace.
And all things are accessible via the keyboard in Code as well as in my preferred desktop environments (XFCE or Windows - macOS, not so much, which is why I don't prefer it). Having the mouse to fall back to is not a bad thing, particularly when you visit someone else's station where they might have configured their editor or desktop differently than you.
If someone gave you a different 500k+ file codebase to maintain, I'd bet that you'd need to browse around a bit before you got familiar enough with things to not need a file browser.
IMO you shouldn't have to do "research" to setup your editor or even simply to use it effectively. With VS Code everything that you need is already integrated and clearly stated - Ctrl+Shift+P to find any command Ctrl+P to open any file in your workspace (no file browser needed). When you want to expand - you have the integrated Extensions marketplace.
And all things are accessible via the keyboard in Code as well as in my preferred desktop environments (XFCE or Windows - macOS, not so much, which is why I don't prefer it). Having the mouse to fall back to is not a bad thing, particularly when you visit someone else's station where they might have configured their editor or desktop differently than you.
If someone gave you a different 500k+ file codebase to maintain, I'd bet that you'd need to browse around a bit before you got familiar enough with things to not need a file browser.
When I use emacs, I hardly have any shortcuts memorized. I just use smex, which has fuzzy matching for commands. When I wanted to open a file, I wasn't sure what command would do that, so I pressed M-x and typed "file." One of the suggestions was, "find-file," so I chose that one, and it gave me a prompt for which file to open, I entered the path in an interface that also had similar fuzzy matching, and I was ready to go. Afterwards, a brief hint told me the key command if I don't want to bother typing, "finf," but I don't really use it.
The command pallette in VSCode is pretty nice too, but I don't recall having quite as nice an experience using it. I still do my professional work in VSCode, though. Emacs is for fun.
The command pallette in VSCode is pretty nice too, but I don't recall having quite as nice an experience using it. I still do my professional work in VSCode, though. Emacs is for fun.
>Ctrl+P to open any file in your workspace
Vscode fan myself, but that feature came to vim first
Vscode fan myself, but that feature came to vim first
> the idea that you simply don't need to see a file tree is nonsense
Have somebody who uses emacs show you sometime how they navigate the file tree. The "modern UI" graphical representation with a little icon for each node of the tree isn't an advantage.
Have somebody who uses emacs show you sometime how they navigate the file tree. The "modern UI" graphical representation with a little icon for each node of the tree isn't an advantage.
I love using the terminal. And I mostly use vim and for raw editing hardly anything can beat it.
But there are things which a terminal can't to. The article mentionedd the ability of IntelliJ (and derived IDEs) to show the code of functions in a mouse over tooltip. A proper tree to show hierarchy of code. The ability to click and browse and so on. They are really useful things when exploring a code base.
But there are things which a terminal can't to. The article mentionedd the ability of IntelliJ (and derived IDEs) to show the code of functions in a mouse over tooltip. A proper tree to show hierarchy of code. The ability to click and browse and so on. They are really useful things when exploring a code base.
NERDTree will give you file hierarchy, CoC will give you insane-levels of autocomplete that rival or beat intellisense and you can use keybindings to navigate directly to method definitions, typings, anything.
Claiming the terminal doesn't do these things demonstrates the lack of time invested time to learn or discover what's available. Again to each their own, but it seems to be the author claims there are no good editors when they simply are just too eager to "open up vscode".
Claiming the terminal doesn't do these things demonstrates the lack of time invested time to learn or discover what's available. Again to each their own, but it seems to be the author claims there are no good editors when they simply are just too eager to "open up vscode".
Oh, I have vim with tons of plugins and use gvim for simpler discovery of some features I les softne use, thus know that vim isn't strictly bound to the terminal.
But there is a massive difference while browsing code between the IntelliJ style editor and all the vim plugins in the world.
But there is a massive difference while browsing code between the IntelliJ style editor and all the vim plugins in the world.
> Terminal editors don't suck. They require learning and discipline, something that some might argue is becoming a lost art in this field. In the days of "gluing modules together", maybe vim isn't for you, but it's for me and this fluff piece contributed nothing.
I mean, I use vim too. Any project that is sufficiently large benefits greatly from a file handler, there is nothing to be proud about for remembering each and every subfile. Why not just put it right there in view? You can't possibly argue it somehow rots the brain; i mean we aren't even talking about writing code here, it's just accessing files.
I mean, I use vim too. Any project that is sufficiently large benefits greatly from a file handler, there is nothing to be proud about for remembering each and every subfile. Why not just put it right there in view? You can't possibly argue it somehow rots the brain; i mean we aren't even talking about writing code here, it's just accessing files.
Find and replace is laborious in VIM...
https://www.linux.com/tutorials/vim-tips-basics-search-and-r...
In Notepad++ it's easier to do for me... I use Find & Replace VERY frequently as I inherit apps developed by others, Some developers don't need to use it at all because they work on a Single Page App...
We're truly in the era of "If it works for me it's great for everyone", which is truly a bad posture to adopt, because now developers dictate features based on opinion rather than research, polling, testing and facts like they used to in the early days. This is why apps, like Android dialer become annoyingly dysfunctional, because it's made and tested on a small group who have 2 hands rather than also on people who only have one hand (and can't afford 2 clicks to get to a keypad as easily).
CLI has been around forever in terms of development. I understand there are use cases where it's highly useful, but in a world where development should be getting LESS complex, it's a dinosaur that preserves job security because of a huge learning curve.
As an architect I frequently work with non-technical people, and using abstract tools to do my work only complicates my ability to get them to understand what I do. Things should be getting simpler, but they're not.
https://www.linux.com/tutorials/vim-tips-basics-search-and-r...
In Notepad++ it's easier to do for me... I use Find & Replace VERY frequently as I inherit apps developed by others, Some developers don't need to use it at all because they work on a Single Page App...
We're truly in the era of "If it works for me it's great for everyone", which is truly a bad posture to adopt, because now developers dictate features based on opinion rather than research, polling, testing and facts like they used to in the early days. This is why apps, like Android dialer become annoyingly dysfunctional, because it's made and tested on a small group who have 2 hands rather than also on people who only have one hand (and can't afford 2 clicks to get to a keypad as easily).
CLI has been around forever in terms of development. I understand there are use cases where it's highly useful, but in a world where development should be getting LESS complex, it's a dinosaur that preserves job security because of a huge learning curve.
As an architect I frequently work with non-technical people, and using abstract tools to do my work only complicates my ability to get them to understand what I do. Things should be getting simpler, but they're not.
> As an architect
I'll take that at face value, and commend you on your programming knowledge. If you're actually a code jockey, let me intone:
Software architects are not architects. Software engineers are not engineers. Computer science is not science.
I'll take that at face value, and commend you on your programming knowledge. If you're actually a code jockey, let me intone:
Software architects are not architects. Software engineers are not engineers. Computer science is not science.
I prefer the terminal as well. Maybe he should just take the time to make a proper vimrc file and stop hyperventilating.
> Terminal editors are out of date. By this I don’t mean that they’re obsolete; I mean their user experience is lagging far behind modern standards. Using editors like Vim and Emacs is not a good experience for the user.
You... you are aware that you can run emacs not in a terminal, right? Use the mouse and resize split buffers and everything? It's okay if you still don't think it's good enough, just... don't pigeonhole it quite like that.
You... you are aware that you can run emacs not in a terminal, right? Use the mouse and resize split buffers and everything? It's okay if you still don't think it's good enough, just... don't pigeonhole it quite like that.
Modern GUI emacs has basically all of the features that the OP’s rant mentions (You can even run WebKit inside of emacs, if you want), but they have to be configured. It seems likely that they haven’t tried emacs in a while, because the rant demands things about packages that already exist. If this were a serious request for help rather than a rant, “Use Spacemacs or Doom-emacs” would be a fine response.
That said, there’s nothing wrong with a little rant now and then. There’s a pretty pervasive feeling among programmers that our tools for interacting with code certainly could be better, and probably should be. I assume the OP is hitting one of those moments right now.
More seriously, though, I believe that there is an answer to the headline question: we don’t have better code editors because the people with the combination of skill, desire, and opportunity almost always fall into one of the two traps:
1.) If they want to make a better general editor for experienced, skilled programmers, then they get sucked into learning an existing editor (usually emacs or vi, sometimes both) on the way, and they find that once you are proficient, those are really quite powerful coding environments.
2.) If you want to make a better general editor for people learning to code, then they tend to create something that is limited (simplified, streamlined, etc). Along the way, they either stop at a version that’s good enough (there are lots of these around), but definitely missing things that are important to (a smaller group of) skilled, experienced programmers – at which point, see #1. The strongest candidates survive, and some of them go quite far (Linus Torvalds uses a fork of micro-emacs, there are people at Google who use nano, etc.)
In the end, the “editor wars” between emacs and vi came down (IMNSHO) to a question between “fast and lean” vs. “expandable”. In the end, both became ”expandable enough”, and software growth (bloat) grew so extensive that both became “fast and lean enough”.
That said, there’s nothing wrong with a little rant now and then. There’s a pretty pervasive feeling among programmers that our tools for interacting with code certainly could be better, and probably should be. I assume the OP is hitting one of those moments right now.
More seriously, though, I believe that there is an answer to the headline question: we don’t have better code editors because the people with the combination of skill, desire, and opportunity almost always fall into one of the two traps:
1.) If they want to make a better general editor for experienced, skilled programmers, then they get sucked into learning an existing editor (usually emacs or vi, sometimes both) on the way, and they find that once you are proficient, those are really quite powerful coding environments.
2.) If you want to make a better general editor for people learning to code, then they tend to create something that is limited (simplified, streamlined, etc). Along the way, they either stop at a version that’s good enough (there are lots of these around), but definitely missing things that are important to (a smaller group of) skilled, experienced programmers – at which point, see #1. The strongest candidates survive, and some of them go quite far (Linus Torvalds uses a fork of micro-emacs, there are people at Google who use nano, etc.)
In the end, the “editor wars” between emacs and vi came down (IMNSHO) to a question between “fast and lean” vs. “expandable”. In the end, both became ”expandable enough”, and software growth (bloat) grew so extensive that both became “fast and lean enough”.
Summary: I would like a vscode that better integrates modal editing.
Verbosity is an existential threat.
Verbosity is an existential threat.
>a terminal does not a pleasant user experience make
Author doesn't establish this, just takes it as a given. I wonder what features terminal emulators/editor programs would lack that are afforded by GUIs? I consider the terminal text editing experience far more efficient
Author doesn't establish this, just takes it as a given. I wonder what features terminal emulators/editor programs would lack that are afforded by GUIs? I consider the terminal text editing experience far more efficient
Efficient is not necessarily a pleasant user experience though, is it?
I am not downplaying anyone's preference of one over the other. However, a better UX would mean that the initial learning curve to start with something should be low, which isn't usually with terminals.
>However, a better UX would mean that the initial learning curve to start with something should be low, which isn't usually with terminals.
Depends how you define better. If you do something very often a steep learning curve with long term payoff can be the better UX seen as a whole.
I use almost only VSCode mind you, but I can see the argument here. I know a bit of vim and it is practical when configuring servers via PUTTY. For bigger projects I find it very lacking.
Depends how you define better. If you do something very often a steep learning curve with long term payoff can be the better UX seen as a whole.
I use almost only VSCode mind you, but I can see the argument here. I know a bit of vim and it is practical when configuring servers via PUTTY. For bigger projects I find it very lacking.
Usually? File handling. It's convenient on large projects to have a list of files in view next to the code.
Nerdtree for vim? Emacs out of the box ...
Wtf.
This stuff is decades old
They’re awesome because they’re decades old. That’s a lot of time to get things just the way developers like them.
I disagree. Terminal is modern it's just different to GUIs, of course they were a precursor but I don't think anyone can say that GUIs are supposed to be a replacement, as in, I don't think they can say this in retrospect. It's just a different interface, which to me is much more convenient and intuitive. I can pick up a command line application that I have never used before and get up to speed very quickly. Obviously this does depend on the usage of conventions, such as environment variables, arguments, man pages and so on but because of its perceived "limitation" it probably means that applications in this domain are more alike to each other at least in terms of their interfaces. I am biased of course, I live inside tmux and vim and I would happily just use the framebuffer (and use cmus, newsboat, irssi, mplayer, et al) but I have to use a browser for work so yeah. Vim is a very good user experience, you either have to learn it a lot to be productive, or use a few plugins that gloss over this somewhat, but I don't think it has such a massive learning curve considering its vibrant ecosystem. Emacs on the other hand, and I really like the keybindings (using a subset in the shell) just makes my head hurt.
I think there could be a huge market for a ux effort that brings the somewhat forgotten goodies of old modal editors into the modern world, combining them with new advances like fuzzy searching. I love vim, but it's appalling that we have so many historical baggage creating a gap for the users...
It's so obvious how vim's ergonomics are made for the [adm 3a keyboard](https://catonmat.net/images/why-vim-uses-hjkl/lsi-adm3a-full...) (location of esc, control, arrow keys, etc) and yet we keep making layers of customization or force ourselves to the standard instead of doing the very needed reboot.
It's so obvious how vim's ergonomics are made for the [adm 3a keyboard](https://catonmat.net/images/why-vim-uses-hjkl/lsi-adm3a-full...) (location of esc, control, arrow keys, etc) and yet we keep making layers of customization or force ourselves to the standard instead of doing the very needed reboot.
Erm, we do have good editors? VSCode, Visual Studio, Rider, to name but a few.
I'm not really sure what the OP's beef is here. They begin by bemoaning anything that isn't vim, then move on to say they want a graphical UI, support for plugins, and a bunch of other things that pretty much any IDE has these days.
I think what they really want is a vim extension for VSCode, customised just for them?
I'm not really sure what the OP's beef is here. They begin by bemoaning anything that isn't vim, then move on to say they want a graphical UI, support for plugins, and a bunch of other things that pretty much any IDE has these days.
I think what they really want is a vim extension for VSCode, customised just for them?
>I think what they really want is a vim extension for VSCode, customised just for them?
Exactly. But they don't want to write it themselves.
Exactly. But they don't want to write it themselves.
Vim has plugins that seem to address most of what you note.
Nerdtree gives you see semblance of a graphical UI. I rarely use it since installing fzf and getting better at using buffers. It's much, much easier to press a shortcut and type a partial name. I use Nerdtree when I need to browse the hierarchy. I also previously had ranger integrated into vim which is really nice
Vim has tons of user extensions. Yeah, the package managers aren't great UI but I use vim awesome website to browse and a plug-in install is a simple copy paste of 1 line.
Using tabnine with vim has been really great for autocomplete. It's probably not as good as vs code but it's good enough for me.
Peek at implementation is available via ctags. Configuration can admittedly be a bear but I have a shortcut to jump to the method definition under the cursor that works pretty well.
I'm using neovim which is usually fast and responsive. Some things like folding and syntax highlighting aren't great in certain conditions but you can write scripts to disable those things in those conditions (file name, and probably size even)
I've tried to switch away from vim but the extensibility is better than any other editor I've looked at. Neovim + tmux makes me feel pretty productive
Nerdtree gives you see semblance of a graphical UI. I rarely use it since installing fzf and getting better at using buffers. It's much, much easier to press a shortcut and type a partial name. I use Nerdtree when I need to browse the hierarchy. I also previously had ranger integrated into vim which is really nice
Vim has tons of user extensions. Yeah, the package managers aren't great UI but I use vim awesome website to browse and a plug-in install is a simple copy paste of 1 line.
Using tabnine with vim has been really great for autocomplete. It's probably not as good as vs code but it's good enough for me.
Peek at implementation is available via ctags. Configuration can admittedly be a bear but I have a shortcut to jump to the method definition under the cursor that works pretty well.
I'm using neovim which is usually fast and responsive. Some things like folding and syntax highlighting aren't great in certain conditions but you can write scripts to disable those things in those conditions (file name, and probably size even)
I've tried to switch away from vim but the extensibility is better than any other editor I've looked at. Neovim + tmux makes me feel pretty productive
TabNine is amazing. I use it with SublimeText and it constantly surprises me by guessing correctly what I was about to type, sometimes even when what I'm about to type doesn't exist in any of my codebases.
Use Spacemacs. Take everything that's great about Vim, and Emacs, make the configuration sane, and the features super-discoverable. You'll never look back.
Does anyone know what "modal editing" is?
I've read the article, and it's mentioned several times, but I've no idea what it actually means.
I've read the article, and it's mentioned several times, but I've no idea what it actually means.
Basically, having two ways of interacting with the file: one mode lets you execute commands to edit the file, the other mode lets you type like in a typical GUI editor.
While editing a file in VSCode, I can press CTRL+P, which opens a small command box in which I can type to find a command with autocomplete - like a souped-up version of vim's "colon prompt" (not sure what it's called!) - does that count?
QMK (keyboard firmware) calls that feature a "leader key."
No
OK... what is the difference, as you see it?
vim (I can only really speak for vim here) has several modes for editing. The main ones are: normal, insert, visual. Most people I know (incl. myself) spend most of their time in normal mode, which allows you to manipulate text objects using movements. In insert mode, your key strokes are converted to characters which are inserted into the file buffer. Switching to normal mode isn't really the same as summoning a command prompt into which you enter commands, it's a bit more fundamental than that.
The real difference is that in Normal mode, you have a very complete set of commands bound to each key that either move the cursor from an absolute perspective, relative to current position, or relative to syntax structure. There are also commands that create a selection to transition you into Visual mode (which is cursor selection) with a given syntax block already selected. Finally, all of these commands can be multiplied out `4w` to move four words ahead instead just one word ahead.
The real power of these is twofold. First you can build muscle memory that lets you move around a text file, precisely select text, and edit the text as fast as you can think. Secondly, all of the commands used to edit text can be recorded into a macro, letting you systematically and repeatedly edit text in a way more powerful than find and replace with high-level regex support (which vim and emacs also have). An example macro could be jump to the next define keyword, then jump to the next set of parenthesis (which would typically be a function parameter)and then reverse the parameters of the function. This macro can be repeated to reverse the parameters of every function in a file, as well as in many files in your workspace. This is fast editing of the semantic structure and convention in a workspace. While this is a contrived example, This editing functionality is very useful for many tasks like re-arranging the structure of each object in a large JSON document to fit to a new schema, refactoring code as well as any task that requires automating many repeated edits. Other editors and IDEs have macro functionality, but without the composable structural editing commands in vim (these are also in emacs) you don't quite have the same kind of power. These kind of edits would otherwise need to be done by a separate script, but the interactivity of NORMAL mode commands and macros let you know that it works for one case, repeat the macro individually and check each case as you go to make sure that it worked, and then edit the macro if the command macro needs to be modified for new structures.
Edit: I forgot to mention that normal mode is also very fast and simple which is much more convenient than CTRL-P for a command. 'w' for moving to the next word. 'b' for moving to the previous words. The command chaining is also relatively consistent for editing as well with 'ciw' for 'change inner word' to select the entire word the cursor is on delete it and then enter insert mode and 'ci('for the same but selecting all the text within the first set of parenthesis that contain the cursor. Many vim emulation plugins don't even feature these commands and only have basic modes and hjkl cursor movement.
The real power of these is twofold. First you can build muscle memory that lets you move around a text file, precisely select text, and edit the text as fast as you can think. Secondly, all of the commands used to edit text can be recorded into a macro, letting you systematically and repeatedly edit text in a way more powerful than find and replace with high-level regex support (which vim and emacs also have). An example macro could be jump to the next define keyword, then jump to the next set of parenthesis (which would typically be a function parameter)and then reverse the parameters of the function. This macro can be repeated to reverse the parameters of every function in a file, as well as in many files in your workspace. This is fast editing of the semantic structure and convention in a workspace. While this is a contrived example, This editing functionality is very useful for many tasks like re-arranging the structure of each object in a large JSON document to fit to a new schema, refactoring code as well as any task that requires automating many repeated edits. Other editors and IDEs have macro functionality, but without the composable structural editing commands in vim (these are also in emacs) you don't quite have the same kind of power. These kind of edits would otherwise need to be done by a separate script, but the interactivity of NORMAL mode commands and macros let you know that it works for one case, repeat the macro individually and check each case as you go to make sure that it worked, and then edit the macro if the command macro needs to be modified for new structures.
Edit: I forgot to mention that normal mode is also very fast and simple which is much more convenient than CTRL-P for a command. 'w' for moving to the next word. 'b' for moving to the previous words. The command chaining is also relatively consistent for editing as well with 'ciw' for 'change inner word' to select the entire word the cursor is on delete it and then enter insert mode and 'ci('for the same but selecting all the text within the first set of parenthesis that contain the cursor. Many vim emulation plugins don't even feature these commands and only have basic modes and hjkl cursor movement.
> Other editors and IDEs have macro functionality, but without the composable structural editing commands in vim (these are also in emacs) you don't quite have the same kind of power.
That's the other way around. Modern IDEs don't work on text like vim does, they understand the language. Using e.g. JetBrains IDEs you can do refactoring across an entire code base in a few clicks. Something you can't possibly do because vim (unless you use plugins) doesn't understand the semantics or even the syntax of the language, it's just text.
That's the other way around. Modern IDEs don't work on text like vim does, they understand the language. Using e.g. JetBrains IDEs you can do refactoring across an entire code base in a few clicks. Something you can't possibly do because vim (unless you use plugins) doesn't understand the semantics or even the syntax of the language, it's just text.
> The most limiting factor for my choice of code editors is that I need modal editing. After learning how to use Emacs, and then Vim, I can not imagine going back to the typical non-modal text editing. These editors make it much more comfortable to edit text (and code), and ruined every other way of editing for me.
Truly, v*m rots the brain.
Truly, v*m rots the brain.
This rant reminds me of Gary Bernhardt's talk from Strange Loop 2012[0]. In that talk, Gary shows a true modal editor that has more than just "edit" and "write" modes. His talk focused mostly on visual layers that could be laid overtop of the code, but it made me think adding "debugging" and "git" modes would be nice. I certainly wish git had a dedicated mode every time I use fugitive[1].
[0]: https://www.destroyallsoftware.com/talks/a-whole-new-world [1]: https://github.com/tpope/vim-fugitive
[0]: https://www.destroyallsoftware.com/talks/a-whole-new-world [1]: https://github.com/tpope/vim-fugitive
Because no one can agree on what is "good". It's entirely subjective to each person. One loves vim, one loves Notepad, one loves VSCode, one loves Intellij, maybe someone loves hammer and chisel on stones. Like virtually everything in the programming world, it's all about what gives you the ability to do what you need to do with the least extra effort. Like any tool you need what you need, not what someone else says you need. Arguing about what is better is pointless but common.
His first topic / sub-heading answers the question for itself: people are too fussy about editors. Everyone has different tastes when it comes to editors, some want syntax highlighting, some like integrated command line, some just want plaintext.
There are no two people with the exact same preference in editors, and that's why there are too many editors and yet still a perceived lack of quality overall.
It's also why most people end up customising the ever loving shit out of their own editors anyway.
There are no two people with the exact same preference in editors, and that's why there are too many editors and yet still a perceived lack of quality overall.
It's also why most people end up customising the ever loving shit out of their own editors anyway.
I like that the author has high standards for an editor. He should have. In my opinion VSCode and VS live up to his requirements about out of the box intellisense, inline definition peeking, and extensions that are easy to install (VS Code being better than VS in this regard). They probably don't live up to his model requirement, though, but I think the author could have done a better job of explaining exactly what he wants from this editing mode.
Vim has mouse support. You just need to turn it on in your .vimrc/init.vim with `set mouse=nv` (that specifically enables the mouse in normal and visual modes).
Does that work in terminal? Afaik I had the only working in gvim.
Works for me (iTerm2 + tmux + vim/neovim).
I am kind of excited for Emacs in Rust. I would love something Emacs like that looks modern and easier to manage like VS' ability to easily drag and drop components wherever you need them, and is very fast to boot, think of ST3, CudaText, and co. Then all the bloatware is optional plugins.
I would say VS Code is a good goal, it has everything you need to have an IDE, and yet you don't feel forced to use it.
I would say VS Code is a good goal, it has everything you need to have an IDE, and yet you don't feel forced to use it.
The main reason for Emacs existence is the ability to customize it as you want. That's made possible by Lisp. It is on a whole different level than a VSCode plugin. How does Rust enhance this experience?
I do not get the requirement to be "very fast to boot". My Emacs instance is always running and I use emacsclient as an entrance point for external tools. This is the typical workflow for Emacs users.
I do not get the requirement to be "very fast to boot". My Emacs instance is always running and I use emacsclient as an entrance point for external tools. This is the typical workflow for Emacs users.
I don't want to even think about those things. I don't have to with Visual Studio or VS Code.
I think Emacs and Vim missed how popular js got. That is a reason why Atom and VSCode has tons of plugins for everything including some Intellisense-like completion.
I think I can relate to his feelings. I want vim with default Intellisense of VS Code.
I know about coc-nvim, but I still couldn't get it to work for C++ on Ubuntu 19.04, will try again soon.
I know about coc-nvim, but I still couldn't get it to work for C++ on Ubuntu 19.04, will try again soon.
> I want vim with default Intellisense of VS Code.
Your best bet is probably CLion (it's proprietary) with IdeaVim plugin. It's not perfect but it's probably easier to implement vim-mode into any IDE than turn vim into an IDE.
Your best bet is probably CLion (it's proprietary) with IdeaVim plugin. It's not perfect but it's probably easier to implement vim-mode into any IDE than turn vim into an IDE.
I used to use IdeaVim with IntelliJ, it was utterly awful.
All of the basic commands were wildly incompatible with vi and vim. Example: u (undo). Not only would it add cursor movements to the undo stack, it would also put multiple actions onto the stack as one, so you could only undo them all at once or not at all.
That's the one I remember most -- it's been over 5 years -- but not a single day went by without some utterly flabbergasting surprise when expecting it to, you know, emulate vi/vim.
Somewhat ironically, about 5 years before that, I used some similar plugin for Visual Studio and that one was infinitely better. It cost $99, but my employer paid for it, and it actually performed as advertised.
Even that didn't implement "advanced" vim commands that I like a lot -- like :perldo -- but at least it didn't fail to get even the basics right.
In the end I don't think any IDE vim-mode can be good enough. What I think would be best is if the IDE somehow embedded the actual vim editor.
All of the basic commands were wildly incompatible with vi and vim. Example: u (undo). Not only would it add cursor movements to the undo stack, it would also put multiple actions onto the stack as one, so you could only undo them all at once or not at all.
That's the one I remember most -- it's been over 5 years -- but not a single day went by without some utterly flabbergasting surprise when expecting it to, you know, emulate vi/vim.
Somewhat ironically, about 5 years before that, I used some similar plugin for Visual Studio and that one was infinitely better. It cost $99, but my employer paid for it, and it actually performed as advertised.
Even that didn't implement "advanced" vim commands that I like a lot -- like :perldo -- but at least it didn't fail to get even the basics right.
In the end I don't think any IDE vim-mode can be good enough. What I think would be best is if the IDE somehow embedded the actual vim editor.
Sorry for recommending this. I have a lot of experience with Jetbrains IDE, but not with the plugin itself. I use vim in vim mode occasionally :)
I think the Neovim project has a goal to eventually make the editor easy to integrate in larger applications, as a plugin, which makes a ton of sense.
I think the Neovim project has a goal to eventually make the editor easy to integrate in larger applications, as a plugin, which makes a ton of sense.
Well now I'm sorry that you're sorry! Wasn't my intent, if it works for you and are happy with it, of course you should recommend it. Maybe some people don't even care about actual compatibility, and just want a modal editor. That's fine. I only meant to add my own experience, not discount yours.
TL DR; The author wants a modal editor (like vim) that's also "modern"/graphical.
My view: this is largely a religious issue.
Editor design is like QWERTY keyboards (or beer): preferences are more dominated by your muscle memory and what you're used to, than any objective notion of "good" or "best".
My view: this is largely a religious issue.
Editor design is like QWERTY keyboards (or beer): preferences are more dominated by your muscle memory and what you're used to, than any objective notion of "good" or "best".
Inane article title required for clickbait?
Yes, yes it does. At my fingertips I have access to every single tool and program without needing to clumsily navigate through folders or Finder, whatever it is. Moving my hand away from my keyboard to my mouse to check TS typings is biggest waste of time when I know how to get to any line in any file with less than 3 keystrokes.
> The way these editors achieve this is through graphical representation of the project hierarchy – the file sidebar
I work on a site which is part game engine, part marketplace, and part React application. I have never once used a file tree because I don't need it to understand the code. This isn't a flaw of terminal editors, it's classic PEBKAC.
Terminal editors don't suck. They require learning and discipline, something that some might argue is becoming a lost art in this field. In the days of "gluing modules together", maybe vim isn't for you, but it's for me and this piece contributed nothing.