4 ms·

I know people who use vim, and are hardcore. Yet anything my hardcore friends can do on vim, I can do in IntelliJ or Resharper. However there are things I use r

I know people who use vim, and are hardcore. Yet anything my hardcore friends can do on vim, I can do in IntelliJ or Resharper. However there are things I use regularly in these tools that vim cannot do. These questions are asked honestly and sincerely and I'm genuinely interested in reading responses: At the end of the day, what is the big deal about a modal editor? How does not-having-to-press-ctrl (or alt, meta, cmd, whatever) for the first key give a programmer any advantage? Is it just the number of these commands that are available - and if so, has someone done a count of commands available in products like IntelliJ and Slick-Edit vs vim? What about the stuff that seems to be missing, like contextual refactoring - or are there plugins / scripts for that? Without any such evidence, it does seem to me that programmers want to use vim because of a reputation that hardcore hackers use it, not because it actually improves productivity.

silentbicycle 16y ago
Contextual refactoring isn't present in vi because vi was meant to be used in conjunction with the Unix shell, pipes, and so on. It's not a full environment unto itself the way Emacs is. Search, refactoring, and the like would be handled by shell scripts, awk, perl, parsers made with lex & yacc, etc. Unix itself IS an integrated development environment! There are lots of plugins for vim, but I'm not up on what would be specifically relevant because I do major editing in Emacs. (Also, I think when most developers need that kind of tool support to use a language it speaks volumes about it, but that's me.) I like Emacs's extensibility and multi-buffer design, but prefer vi's modal keyboard interface. I like its brevity and orthogonality. Number of commands is less important when each combines cleanly with the others. I would love to see a synthesis of the strong parts of vi and Emacs, though I don't expect it to ever happen - Emacs's giant bundle of elisp has way too much inertia for a full rewrite. How useful are IntelliJ and Resharper for (say) Erlang, by the way? While I haven't used either, those editors look like they're more tightly focused on Java and C#, whereas vi is for editing any kind of text, and Emacs has had at least passible support for every language I've ever used (except Joy). Comparing vi to an editor specifically designed for Java is a bit misleading.
- binaryfinery 16y ago
  Refactoring could be handled by perl, awk, in theory. Or you could, in theory, right a parser to do it. But I don't know of anyone who has. A simple search and replace, on a big code base simply isn't going to work. You want to add a parameter to a method on class Foo, when 20 other classes have that same method name? What about when Foo is an interface, and you have to do it for the 10 classes with that method name that implement Foo, but not the 50 that dont? m.foo( bar baz); Does this foo need to be changed? You can't know without knowing what type 'm' is. Good luck writing an awk script for that. This isn't a debate about whether or not it could be done. Its about whether or not you can do it faster than I type Ctrl-F6. If such a tool exists that I can run from bash, please let me know. Otherwise you guys have advanced from type-writer to the early dedicated word-processors that existed in the 80s, but no further. Jetbrains have refactoring tools for C#, Java, Javascript, Python, Ruby, PHP, Adobe Flex, as well as "basic" language support for most others (but no Erlang I'm afraid). As you say, vi is about editing text. But the author is a member of the Ruby on Rails core team and a core contributor to Ruby projects, and I put it to you that most people using vim dont use it to edit just text: they edit text that happens to be a language with a formal grammar, and structure both with the file, and outside it: i.e. contextual. Hence, a good IDE will always be better than vim. I also dispute the idea that, given a new language, vim will be better at editing it. My IDE will likely be able to do exactly the same things vim can do, using the keyboard only, and with (on average) the same number of clicks. However, the IDE will most likely be intuitive, obvious, and easy to learn (e.g. by giving visual feedback), meaning that in reality, even though vim could do as much as my IDE for an expert user, for the average user it wont and never will.
  - silentbicycle 16y ago
    Also, I agree that trying to refactor (say) C++ with awk would be hopelessly quixotic. I'm not an idiot. (I have written parsing and static analysis tools for an in-house language, though, just not one as screwed up as C++.) I was explaining the historical reason for vi lacking such features - grammatically ambiguous, overloading-heavy languages that combine static typing with OOP hadn't been invented yet. I think it's bad design to have refactoring tools be a part of the editor, proper, rather than as a standalone tool the editor calls. It's more a matter of static analysis (or runtime introspection) issue than editing per se.
grogers 16y ago
One of the best things about vim for me is (for example) the command cib. This deletes everything from your cursor forward to the first "(", and everything after to the first ")", then places you in insert mode. How do you do that in your editor? I'm guessing you use your mouse to select all this stuff and hit backspace, which is a bunch slower. Moreover, the command cib itself is built from composeable parts - c (not sure what the mnemonic for this is but its delete then enter insert mode), i (inner), b (block of parens). There are several commands besides c - d (delete), < (left indent), = (auto indent), etc. And these compose with any motion, eg gg (goto line 1), G (goto end), w (next word), etc. So you have all these powerful ways to jump around the file, and you can combine them with all these powerful ways to manipulate the file. And this is just one of the really nice things about vim. The "." (repeat last command) is something I haven't found in any other text editor, and was the main reason I got hooked on vim.
- binaryfinery 16y ago
  Ctrl-W is "select word" but it expands each time you press it. So if I'm in the middle of a string, and that string is part of a method call: ( "some string" ) And I press Ctrl-W, then at first "some" will be selected, then "some string", then ""some string"" (with the quotes). So assuming that moving my thumb to Ctrl is free, I did it in the same number of key presses as you. Or its 4 vs 3 if you count the ctrl key. Or its 4 vs 4 if you are in insert mode and have to esc first. [Edit: ok, you have to press delete too, so its 5 vs 3 or 5 vs 4.] The difference, however, is that Ctrl-W is all you have to know. Its just as fast as all your different combinations even for the worst case, but: a) its often faster - i.e. just two Ctrl-W's for selecting the text inside the string. b) it provides visual feedback. Its just as fast for the expert, but yet its obvious, intuitive, and lends itself to discovery based learning. Once you know Ctrl-W selects a word, there's a good chance a user will learn its advanced features by accident, even if they aren't told. Goto line: Ctrl-G 10. Goto first line: Ctrl-Home (standard in most GUI editors) Goto last line: Ctrl-End (also) The '=' auto indent feature: Ctrl-Alt-L Enter is "format entire file". Its fast, so why would you ever want to format just a little bit? Ctrl-Alt-L Alt-A Enter is format the entire project. I dont have a binding for indent, because why would I ever want to? Just write code, then let editor make it look pretty in one go with Ctrl-Alt-L Enter. I assume the "." command is used to say repeat a replace or a find: in which case there are keys for that. I'd like to see some use cases for that other than find and replace. Editors like IntelliJ, SlickEdit, Resharper, all have powerful keybinding support. SlickEdit has a built in scripting language if you want to go crazy. All have far more commands than are actually bound. SlickEdit has a vi mode even. So you haven't convinced me that vim offers any advantage over a good IDE.

silentbicycle 16y ago

Contextual refactoring isn't present in vi because vi was meant to be used in conjunction with the Unix shell, pipes, and so on. It's not a full environment unto itself the way Emacs is. Search, refactoring, and the like would be handled by shell scripts, awk, perl, parsers made with lex & yacc, etc. Unix itself IS an integrated development environment! There are lots of plugins for vim, but I'm not up on what would be specifically relevant because I do major editing in Emacs. (Also, I think when most developers need that kind of tool support to use a language it speaks volumes about it, but that's me.) I like Emacs's extensibility and multi-buffer design, but prefer vi's modal keyboard interface. I like its brevity and orthogonality. Number of commands is less important when each combines cleanly with the others. I would love to see a synthesis of the strong parts of vi and Emacs, though I don't expect it to ever happen - Emacs's giant bundle of elisp has way too much inertia for a full rewrite. How useful are IntelliJ and Resharper for (say) Erlang, by the way? While I haven't used either, those editors look like they're more tightly focused on Java and C#, whereas vi is for editing any kind of text, and Emacs has had at least passible support for every language I've ever used (except Joy). Comparing vi to an editor specifically designed for Java is a bit misleading.

binaryfinery 16y ago
Refactoring could be handled by perl, awk, in theory. Or you could, in theory, right a parser to do it. But I don't know of anyone who has. A simple search and replace, on a big code base simply isn't going to work. You want to add a parameter to a method on class Foo, when 20 other classes have that same method name? What about when Foo is an interface, and you have to do it for the 10 classes with that method name that implement Foo, but not the 50 that dont? m.foo( bar baz); Does this foo need to be changed? You can't know without knowing what type 'm' is. Good luck writing an awk script for that. This isn't a debate about whether or not it could be done. Its about whether or not you can do it faster than I type Ctrl-F6. If such a tool exists that I can run from bash, please let me know. Otherwise you guys have advanced from type-writer to the early dedicated word-processors that existed in the 80s, but no further. Jetbrains have refactoring tools for C#, Java, Javascript, Python, Ruby, PHP, Adobe Flex, as well as "basic" language support for most others (but no Erlang I'm afraid). As you say, vi is about editing text. But the author is a member of the Ruby on Rails core team and a core contributor to Ruby projects, and I put it to you that most people using vim dont use it to edit just text: they edit text that happens to be a language with a formal grammar, and structure both with the file, and outside it: i.e. contextual. Hence, a good IDE will always be better than vim. I also dispute the idea that, given a new language, vim will be better at editing it. My IDE will likely be able to do exactly the same things vim can do, using the keyboard only, and with (on average) the same number of clicks. However, the IDE will most likely be intuitive, obvious, and easy to learn (e.g. by giving visual feedback), meaning that in reality, even though vim could do as much as my IDE for an expert user, for the average user it wont and never will.
- silentbicycle 16y ago
  Also, I agree that trying to refactor (say) C++ with awk would be hopelessly quixotic. I'm not an idiot. (I have written parsing and static analysis tools for an in-house language, though, just not one as screwed up as C++.) I was explaining the historical reason for vi lacking such features - grammatically ambiguous, overloading-heavy languages that combine static typing with OOP hadn't been invented yet. I think it's bad design to have refactoring tools be a part of the editor, proper, rather than as a standalone tool the editor calls. It's more a matter of static analysis (or runtime introspection) issue than editing per se.

grogers 16y ago

One of the best things about vim for me is (for example) the command cib. This deletes everything from your cursor forward to the first "(", and everything after to the first ")", then places you in insert mode. How do you do that in your editor? I'm guessing you use your mouse to select all this stuff and hit backspace, which is a bunch slower. Moreover, the command cib itself is built from composeable parts - c (not sure what the mnemonic for this is but its delete then enter insert mode), i (inner), b (block of parens). There are several commands besides c - d (delete), < (left indent), = (auto indent), etc. And these compose with any motion, eg gg (goto line 1), G (goto end), w (next word), etc. So you have all these powerful ways to jump around the file, and you can combine them with all these powerful ways to manipulate the file. And this is just one of the really nice things about vim. The "." (repeat last command) is something I haven't found in any other text editor, and was the main reason I got hooked on vim.

binaryfinery 16y ago
Ctrl-W is "select word" but it expands each time you press it. So if I'm in the middle of a string, and that string is part of a method call: ( "some string" ) And I press Ctrl-W, then at first "some" will be selected, then "some string", then ""some string"" (with the quotes). So assuming that moving my thumb to Ctrl is free, I did it in the same number of key presses as you. Or its 4 vs 3 if you count the ctrl key. Or its 4 vs 4 if you are in insert mode and have to esc first. [Edit: ok, you have to press delete too, so its 5 vs 3 or 5 vs 4.] The difference, however, is that Ctrl-W is all you have to know. Its just as fast as all your different combinations even for the worst case, but: a) its often faster - i.e. just two Ctrl-W's for selecting the text inside the string. b) it provides visual feedback. Its just as fast for the expert, but yet its obvious, intuitive, and lends itself to discovery based learning. Once you know Ctrl-W selects a word, there's a good chance a user will learn its advanced features by accident, even if they aren't told. Goto line: Ctrl-G 10. Goto first line: Ctrl-Home (standard in most GUI editors) Goto last line: Ctrl-End (also) The '=' auto indent feature: Ctrl-Alt-L Enter is "format entire file". Its fast, so why would you ever want to format just a little bit? Ctrl-Alt-L Alt-A Enter is format the entire project. I dont have a binding for indent, because why would I ever want to? Just write code, then let editor make it look pretty in one go with Ctrl-Alt-L Enter. I assume the "." command is used to say repeat a replace or a find: in which case there are keys for that. I'd like to see some use cases for that other than find and replace. Editors like IntelliJ, SlickEdit, Resharper, all have powerful keybinding support. SlickEdit has a built in scripting language if you want to go crazy. All have far more commands than are actually bound. SlickEdit has a vi mode even. So you haven't convinced me that vim offers any advantage over a good IDE.