You may have read a recent article suggesting that vim is great unlike IDEs, because of their allegedly low typing speed.
Let’s recall that the main message of that article was that vim’s killer feature consists in its modes that sort of outshine everything else. That said, the author acknowledged that IntelliJ IDEA and other IDEs provide hotkeys and other user experience which can be easily used. However, since they lack modes, vim is supposed to be everyone’s first choice.
The author then suggests that instead of pressing
ctrl+arrows to move between words, it is easier to press Esc, e and then go back to the i editing mode. Understandably, all this trouble because the author finds it inconvenient to hold ctrl.I know that articles that criticize vim get many negative votes, but I just have to speak out.
Are your lines of code so long that your finger grows tired holding the key to the point where you really need modes? I can get it when you are typing a long constant — in this case you can press Caps Lock and type its name. Even then I hardly press this key more often than once a year. But to switch modes back and forth for moving forward down a couple of words, let alone to call that vim’s killer feature, sounds like a bit of a stretch.
By the way, in IntelliJ IDEA, you can change the case of a word (or the selected text) with one key, so it does not really require using Caps Lock either.
I admit that vim can be good for editing config files on a remote server. Also, vim can be great for new languages that have not yet been played around with by JetBrains. Writing custom plugins is easier for vim (but in 99% of cases you won’t need them with an adequate IDE). Perhaps, it is more convenient for editing long texts. But that is irrelevant for standard industrial coding!
I should at once mention several points here.
Vim can be turned into a kind of IDE by installing plugins and learning hotkeys to operate those plugins
It can indeed, but why would anyone bother?
It seems like a weird challenge considering that IDEs have it all, and with a much more user-friendly experience. You won’t have to use a mouse, I promise!
Let me explain the thing with editing without a mouse by using an example. I first open IntelliJ IDEA and create a new file.
I press p, and the IDE immediately prompts me with a suggestion of the word package. All I need to do is press Enter to put the word package into the text inside the editor.
Then I press
c, and the IDE suggests class at once.I enter the name of the class (e.g.,
Habr), type the curly brace {, and the IDE automatically completes the closing brace just behind the cursor.Then I type pu, and the IDE understands that it’s probably public. I type in
H and press Enter to get Habr, because the IDE has already got it that I want to create a constructor.I proceed to writing the body of the constructor, e.g. I call the init() method, which is not there yet. My IDE highlights it with red color, which indicates that this method does not exist. Once I press
alt-ENTER, the IDE will insert the code snippet in the right place: private void init() {
}If I happen to type
new Habr(5) inside this method (the word Habr was also prompted of course), i.e. if I try to call a non-existing constructor, IntelliJ IDEA will underscore that bit right away, so I just press <alt-ENTER> and choose what exactly I want to do: whether it is to add an int argument to the constructor or add a new constructor with an int parameter. I choose the latter option, and the IDE immediately adds a new constructor after the first one:public Habr(int i) {
}I won’t mention the automated indentation and other features that help you edit the code, since naturally they are present.
Here is what I got in the end:
package x;
class Habr
{
public Habr()
{
init();
}
public Habr(int i) {
}
private void init() {
new Habr(5);
}
}All I did was literally hit a couple of keys and the
<alt-ENTER> hotkey.I did not install any plugins.
I did not have to train for a month to be able to do this.
I NEVER TOUCHED THE MOUSE (I used Caps Lock here not because I wanted to shout out like a nutcase, but because it was fun to try the feature).
I did not switch to any modes and did not have to recall any key or knob combinations. The only one I used was
<alt-ENTER> (but that was a context-dependent thing, a sort of a “problem solving” hotkey).If you hate using the mouse, you can navigate through the code using special hotkeys, such as for jumping to the right class, file, method, line number, etc.
You can select text by repeatedly pressing
<ctrl-W> to select the current word, the current text between the braces, etc.Vim allows you to jump to a particular character. For example, you can get to a letter x in the line of text without touching the mouse. Yet an IDE also gives you this opportunity through pressing
<ctrl-f> and typing in the required chunk of text. This is also a sort of a mode by the way. It is called the search mode, duh!I also don’t need the mouse to jump to the right function call and then, again without the mouse (press
ctrl-b), to jump to the description of this function.Vim has several unique out-of-box editing features that are missing in IDEs
- Move to the next/previous paragraph.
Yes, it sounds like a useful feature for an IDE. But rather for editing articles for Habr than for actual coding. - Move to the next space character.
Well, you can call it a useful feature, but not too cool. The repeated pressing ofctrl+arrowswill produce the same effect. - Jump half a page up/down.
I haven’t yet decided whether I need this one for anything. - Jumping to the first/last/middle line on the screen.
I don’t really see what this is for. That is, it may come handy some time, but it is by no means a killer feature. - It is possible to delete exactly N lines of code.
Yeah, right, I do this every day. Everybody needs to delete exactly 19 lines of code from time to time, right?
I am in no way a vim guru, so I may have missed some key aspects. Please share your thoughts in the comment section. Yes, of course there are zillions of plugins on top of that. But IDEs also have them, and in comparable quantities.
Summary
Here is my own take-away from this. I will stay away from vim when it comes to code editing, no matter what you’ll say. I was not very impressed with using modes instead of holding ctrl or even
ctrl-alt-shift. IDEs give you more out-of-box features, without the need to spend a while on learning and assigning hotkeys. Most everyday tasks can be accomplished with an IDE by learning just a couple of hotkeys. You can even skip them altogether if you are happy using the mouse.It has long been established that a programmer takes more time to learn code than to actually write it. So whether you’ll use your mouse or not does not make big difference. However, let me reiterate that IDEs allows you to do almost everything (if not everything) without using the mouse.
Vim will work better than nano for remotely editing config files on a server, provided that the following conditions are satisfied:
- You need to have a good grip of vim.
- You need to edit industrial quantities of config files to feel the advantage. If you only need to make changes to one configuration file once or twice a month, nano or indeed anything at all will work well.
You can start voting me down or, better still, offering your counter-arguments :).
Комментарии (6)
poxvuibr
15.01.2019 18:17Ok, since I don't think you are going to translate my article about modes being vim's killer
feature, I'll just make a short reply.
Somehow, the post I made so that everybody knew, that there's no need to publish posts like the one I'm commenting right now, lead to someone publishing the post.
I just can't understand, how author could see things I didn't put there.
For example:
You may have read a recent article suggesting that vim is great unlike IDEs, because of their allegedly low typing speed.
I didn't say, that vim was better, I just said, what it's main feature was.
Also, I didn't say, that IDE is not great. Here's what I wrote:
IDE make programmers job so much easier, that if you're not using it, you probably have a lot ot explain
And of course I didn't say, that IDE makes you type slowly. I mean, I explicitly wrote, that it's not about speed at all:
I don't want to say, that everything is faster, if you use modes, I want to say, that vim users find that using modes is more convenient and pleasant.
How could anyone miss that?
So, those things, which author considered to be main points on my post, actually weren't there. And then, author states his opinion on vim, which is almost exactly the same as in the post he criticizes.
Here's my text:
Also, you find out that people actually use vim to write code. I mean, it's 21 century you can download Visual Studio, Intellij Idea or, god forbid, Eclipse any moment you want, and they use vim. On their on volition.
And here's what author wrote:
vim can be great for new languages that have not yet been played around with by JetBrains. Writing custom plugins is easier for vim (but in 99% of cases you won’t need them with an adequate IDE). Perhaps, it is more convenient for editing long texts. But that is irrelevant for standard industrial coding!
So the hypothetical programmer from my post, thinks the same as author. And my post was meant to explain guys like that, why modes were vim's killer feature. Regrettably, I see, that I have failed.
And then author practically recites Dr. Watson from the picture. Yes, my post has picture of Dr. Watson, saying, that he can't understand why people would use vim to code )).
Vim can be turned into a kind of IDE by installing plugins and learning hotkeys to operate those plugins
It can indeed, but why would anyone bother?Author informs us, that IDEs have same features vim has, but IDEs are more convenient.
I explicitly wrote, that modes are more convenient for vim users, but author didn't pay any attention.
Because if something was inconvenient for the author, that couldn't possibly be convenient for anyone else, right?
So, the post should've been named — How modes could be vim's killer feature? I don't like them!. That would explain a lot.
Seriously, author starts enumerating features IDEs have, even though I explicitly wrote, that it's wrong to say, that vimmers cope with modes, because vim has a lot of features. It's more correct to say, that vim users add features to vim, so that they could continue using modes.
Maybe he didn't believe me, it's hard to say.
In the end author wrote:
I am in no way a vim guru, so I may have missed some key aspects.
Yeah, you have missed MOST of the text, you're replying to.
Also, I'd like to answer the question author asks.
Yes! Seriously! Modes are vim's killer feature! Yes, people use vim it has modes! Yes, modal editors are comfortable to use for a lot of people! Really!
varanio
17.01.2019 14:01Thank you for the comment. I think it's wierd and unfair not to translate your original article.
Cheater
16.01.2019 02:51+11. What is the point of creating a topic in English as a follow-up for a topic in Russian? The OP is a native Russian speaker, and you are, and most of the expected commenters are. Nevertheless we are forced to communicate in English here. I feel like I found myself in an asylum.
2. You are making a pretty stereotypic mistake <for Vim critics>, which is, you think that a set of some IDE's *hotkeys*, however complete/comprehensive it is, is conceptually the same as Vim's modality capabilities. (You also drag code snippets and autocompletion into discussion for no reason — btw vim also has those.)
Vim modality is NOT just an existence of a mode consisting only of hotkeys. As a bare minimum, Vim's <N> mode is a command system that allows command chaining and applying commands to dynamically constructed targets (consider «da(»). I doubt Idea's hotkeys can simulate that. Vim modality is a huge world, and one-letter hotkeys — and even the [text objects](http://vim.wikia.com/wiki/Creating_new_text_objects) (N lines, paragraphs) you are briefly mentioning are only a tip of the iceberg. Any comment on Vim macros? :s capabilities? Hotkey/command history capabilities? This is, in fact, another mistake typical for Vim critics: their Vim knowledge and <N> knowledge rarely stretches beyond hjkl and basic positioning/editing commands (which they usually pick as targets for critics, thinking they are targeting the complete «vim way»). The most advanced of those learn text objects, substitution, and ex commands, and think they *finally* mastered vim and are ready to make unbiased judgements. (Not even close.)
3. Regarding a month-long training: Some dev tools are subject to months and years long study. Most people are perfectly ok with spending years for mastering e.g. C++ or networking; mastering a CUSTOMIZABLE personal toolchain (at least, customizable to the extent of programmable text editors like Vim, Emacs or Sublime, not of out-of-the-box-ready IDEs; not even speaking of PIM and productivity tools) is an equally hard task.Cheater
16.01.2019 04:09-1My bad, I missed the «translation» tag. This topic has a (pretty old) Russian original counterpart and I now remember commenting on it earlier.
A business idea for TM: autogenerate automated Russian->English translation for all the past articles. English speakers should feel the same pain as us readers of Aliexpress automated translations.
exr
Vim is resource effective and great in cases when such features of code autocompletion and others are overkill.