Oh yes, this is why I find Vim much better than any other editor. Because
I don't need to think about editing, it just happens as I need and when I need.
I personally am a fairly lazy person, so moving my hands away from the keyboard all the time to reach the mouse is just too much, and I get tired fairly fast. That's the main reason I use vim.
Same, though I don't know if tired is the best word for me. For me, its just like, whats the point? Being able to use a computer without having to move my arms more than an inch or so is kind of...relaxing?
An upgrade I've made to my Alphagrips (with the optical trackball) is to use either a stainless steel ball or a teflon ball instead of the cheap plastic trackball.
Edit: Just remembered I also replaced the tiny balls holding the trackball with teflon balls. I think the biggest improvement was just from replacing the main trackball though, I rarely have to clean the sensor/rollers anymore.
My biggest issue other than that is the behavior of Shift doesn't match other keyboards :\ Can't shift click to select ranges of text.
It's annoying, but one also loses focus. I'm also a huge fan of i3wm, which is a tiling wm that requires no mouse in order to be used, so I can move around without actually moving my hands off the keyboard.
It's not about the amount of lines I write, since vim would barely give me any benefit. It's moving around, for example, when you really feel the difference. And it's not only vim, but other stuff that I also have configured to not have to use the mouse (like firefox, through vimperator, or the wm, through i3wm).
Don't get me wrong. I don't have anything against IDEs. I've been playing around with neovim's msgpack (the thing that would theoretically allow neovim to be embeded inside Intellij, for example) and if I get some time, I might start implementing an Intellij plugin to allow me to use neovim (ideavim is very buggy, unfortunately. I really appreaciate the author's effors, though, but the way to go in the long term is through neovim).
Okay, so you basically want to interact with your UI using only using keyboard shortcuts. I would agree that it does indeed provides a productivity boost.
I still believe that if you are productive in an IDE like, for example, Intellij, there is no point to really go to vim. What I often recommend is that people give it a try, even if it's sublime's vintage mode or ideavim, which is pretty good out of the box (but very buggy if you get into customizing). At the end of the day, vim is another tool, and tools are there to help us be more productive. I don't work with very large projects nor do I usually do any sort of refactorings, so vim works very well in my use case, but I very much understand when people complain that vim doesn't do what they need. I run a very customized version of vim (15 plugins or so plus around 400 lines of config in total), so, as you can expect, it's very hard for me to leave it :-).
I use vim and git to manage my todo lists. I use vim to take meeting notes, and leverage pandoc to produce aesthetically pleasing pdfs to mail out. I use vim when writing my documentation in Markdown and/or reStructured Text. Vim is my default text editor for pretty much everything.
I bought a thinkpad keyboard with a trackpoint for just that reason.
I prefer not using the mouse at all, and rarely do when I'm using emacs, but for any other apps and most websites it's unavoidable. The trackpoint is right there under my index finger and the mouse buttons convenient for thumbs. Far better than reaching for a mouse or even moving your hand down to a touchpad.
I do have a Thinkpad, as well, and I also use the Trackpoint :-). Very convinient, indeed. It's one of the things I cared the less about when I bought it and now it's one of the things I can't live without.
This was what originally attracted me to Vim, but I found it similarly jarring to jump all the way to the Esc key every time I wanted to switch back to execute mode. I couldn't fathom why such a poor choice was made for that key until I saw the computer it was created on: http://www.catonmat.net/images/why-vim-uses-hjkl/lsi-adm3a-f...
My .vimrc now has "inoremap jj <Esc>" in it, and that was the final missing piece to get me into uninterrupted-productivity mode with Vim. Since you seem to have similar preferences, you might find that a useful optimization.
I do the exact same thing, but with the 'jk' keys. It works really well. I also have 'JJ' (insert mode) mapped to create a new line on top of the current line and go into insert mode, and 'jj' (insert mode) to create one line under the current line and go into insert mode. It seems like it makes no sense, but I have gotten used and works wonderfuly (I could finish writing the parameters for a function inside the parentheses, press jj and simply open the braces that make the function's body, instead of having to go to escape mode or having to press ')' and then enter to get out of the parentheses and go to the next line.
I don't understand neither of you two. Why bother with jj or jk when there is
<Ctrl-C>? There are few cases when it differs from how <Esc> works, but those
are rare and make changes big enough to justify jumping to <Esc> anyway.
It's faster, in my opinion. Using ctrl is one of the reasons people end up with the pinky things in emacs. jk is in my home row. I would rather avoid having to reach the ctrl key. I think ctrl-[ does the exact same thing as ctrl-c. It's just a matter of preference.
I don't really have occasion to press the ctrl key in the course of normal typing in vim, so it's much easier for me to hit jj. In particular, jj is right under my right index finger which makes it one of the easiest key-combos to hit without too much travel or thought.
As a front end web developer, I am not really sure I understand any "advantages" to VIM or VI, or any command-line based edit for that matter. Sure, they might be great if you're doing scripting, messing around with the back end, or dong DB stuff. But for me, writing day-to-day JS, HTML, CSS code, VIM seems like a very huge burden. It's like trying to unscrew a screw with scissors when you have a screwdriver laying next to you. Why not just use a good, well-rounded editor like Sublime or Atom, or even Eclipse, for that matter..? I often see web developer, dabbling in front end code, doing their coding in VIM. Yuck. Someone explain?
VIM has a learning curve, but once you're over the hump you can do many kinds of edits much faster than using the mouse. You need to join two lines of text? It's one key press. Transpose two lines of text? Three key presses. Also macros are very easy to define and use (once you understand how they work).
What would you say is the learning curve? From someone who is used to GUI editors, moving to VIM...how long until you're actually reaping the benefits?
It took me a week to be comfortable with the mode change, then 1 month to be relatively comfortable with Vim... and 5 more month to properly reap some of his advantage when editing text. It may seem a long time, but it's taking me the same time to be comfortable with emacs right now, and from what I remember, with other editor more or less the same difficulties arise (I've never tried Sublime enough for example, but for Textmate it took me less time only because the feature set is narrower... habits themselves took the same time to kick in)
Play VIM Adventures[1]. Even doing a few levels was enough for me to start enjoying benefits. And I didn't switch from Visual Studio for the bulk of code editing, I just added VsVim. That way I'm not forced into VIM. I can use as much or as little as I want. No pressure. (Though all my config editing is over SSH and VIM itself is great there.)
The biggest, easiest, thing for me was macros. Being able to easily and quickly record a macro and apply it over many lines - that's slick. Like converting a CREATE TABLE to a set of ORM instructions, or into a structure. Before I'd use some half cooked regex and clean up after. Now I just edit one l line while in a macro then run it N times.
Apart from that, it's just a ton of little things that add up.
Also: ViEmu for Office. VimFx for Firefox (there's one for Chrome too, Vimium). Browsing without the mouse is really great; quite elegant.
Spend 2-3 hours and learn the basic movement methods, this brings you at a comparable speed with a mouse-based editor. After a week of using you'll develop muscle memory and you're already faster. At least that's my experience with teaching other people so far.
It took me a day to use it as "notepad with syntax highlighting", couple of weeks before I started preferring normal mode to insert mode, and from there on I slowly evolved my configuration and the tricks I use/learn.
Nowadays when using vim I occasionally have people ask me "how did you do that?" and I won't even know what keys I typed. The keybindings are as natural as walking/grabbing things and require as much conscious thoughts. I usually have to redo it in slow motion to see what I did...
I can highly recommend Bram Moolenaar's essay on "The Seven Habits of Effective Text Editing" (http://www.moolenaar.net/habits.html), it has a vim focus, but I think his points are editor agnostic
Edit: I started using vim as a windows GUI person in university since I wanted to edit over SSH and vim was the only editor with syntax highlighting on the servers. So it's not like I was a terminal wizard back then (I am now :p)
I'll start off with the best advice I ever ran across with regards to the beat to death "choosing an editor" question:
> Try all the popular ones, give them all a fair shot like several weeks of exclusive use. Pick one. Practice it. Move on to more interesting problems.
Vim is a good well-rounded editor that can do anything Sublime or Atom can do. And it did them before Sublime or Atom existed. It has Gui's that feel native.
Every new generational crop of editors, I give the new guys a fair shot. Use them for a few weeks, but usually end up back on Vim after that. Last one that really "shook things up" was TextMate...though all editors have those features now.
So, to your question specifically: Why vim?
I could go on about keyboard efficiency or home row or more terse key combos to get the same thing done or blah blah blah. But really, none of that is true.
The reason I use vim is simple: It's feature full, does everything I need, I know it and know it well, and....
I've got better things to do then learn another editor as well.
I think you missed the point. I believe the idea is that there isn't One Editor To Rule Them All. You can try out new text editors, but in the end, just pick whichever one feels right for you, and move on.
> Why not just use a good, well-rounded editor like Sublime or Atom, or even Eclipse, for that matter..?
Because those editors use GUI that isn't optimized for editing text. They use the same widgets that are used by the Volume Manager, the Finder, the web browser. Vim's interface is geared only towards editing text.
Ah yes, the infamous volume-manager-that-you-have-to-adjust-with-a-text-field, I hate that thing.
According to you VIM isn't optimized for editing text. It uses a UI (terminal) that was designed for entering batch commands and displaying their output.
The terminal isn't a UI, and VIM doesn't use any UI toolkit, not even curses, but rather is completely custom. This enables it to specialize in text manipulation, whereas graphical editors like Sublime build on top of the OS-provided UI and keyboard conventions. Some prefer the latter because it is more "familiar", but personally I think the fact that VIM is its own thing is what makes it special.
>It's like trying to unscrew a screw with scissors when you have a screwdriver laying next to you.
I kind of felt the same way when I first started learning vim. It seems "foreign" at first, but now that I'm able to use it pretty proficiently I think this is a bad comparison.
Vim is more like a power screwdriver that not just anyone can handle, but once you get the hang of it you never want to use a regular screwdriver again.
Vim, unlike other editors, usually requires customization though, so you really have to emerge your self in vim to get up-and-running whereas with an editor like atom you're typically good to go.
I'm a full stack dev and I use vim for everything. From back end system admin to front end.
I don't need any IDE fancy stuff when MVC is pretty straight forward.
If I need to split screen or jump between window it's tmux or vsplit/split on vim really. I don't use many commands with VIM.
Plus most front end tools are cmdline. bower, composer (for php), grunt, npm, etc... I also use vagrant to run my projects and ansible those are mostly cmdline.
I guess in general, I like the fact I have everything in control in one terminal.
I don't have to jump or juggle between different programs. IDE, Commandline, and bunch of other programs.
Some IDE might have bower, grunt, etc.. extension tuck in somewhere where I have to search for. No thanks.
I got tmux and I don't have to jump between window just to restart or do stuff with vagrant either.
edit: I know about 15 at max vim command. >___<. And like maybe 8 commands for tmux.
> Why not just use a good, well-rounded editor like Sublime or Atom
I'd like to ask you the same question: what makes you think Sublim or Atom is a superior text editor (not: I'm not talking IDE) ?
Personally I took the time to learn and be proficient with vim; it is now my editor of choice because it gives me a lot of power and doesn't get in the way. It did take time, but it was worth it. I'm pretty sure if I chose another editor I would be equally proficient; it's not so much about vim being the best one, it's more about how I'm efficient with it today.
I guess you've been turned down by vim because it's hard to start with, and in that sense Sublime or Atom are certainly better text editors ... but it doesn't matter, because the learning phase is only temporary.
I would say Vim is not good or well rounded until you cobble together a set of addons that let you do things that many IDEs (and text editors) do out of the box.
Even as a text editor - it doesn't come with things like bookmarks, navigable hyperlinks, syntax highlighting, collapsible sections, etc without plugins.
You've got me on navigable hyperlinks with a simple setting or key stroke out of the box, but it's trivial to write a binding to open the URI beneath the cursor.
I strongly disagree. They're all very powerful features that don't require anything to be useful, if not user friendly, out of the box in a reasonable distribution of vim.
Eh, I use all of those extensively...vim ships with syntax highlighting and syntax aware folding for every obscure language I've ever used (well, there was one academic project language that didn't ship those with vim, but guess what, they had those files in their repository).
Marks are powerful and play really well with all the movements like I'd expect them too...
So, you regularly use vim without any plugins then?
Marks doesn't even have a visual indicator. So, somehow I doubt you're just using marks for bookmarking and vanilla syntax highlighting is pretty weak.
Let's see your list of plugins. I bet you have at least 30 of them.
Edit: Forgot to answer the initial question. Yes, I use vim exclusively for anything involving editing/writing. In the past years mostly C, C++, Haskell, LaTeX, Java, python...
Largest codebases I've worked with were upwards of 200k SLOC.
Mostly it depends on where you are coming from. The key is that you'd want to avoid context switches. All my other tools are CLI, so adding an editor in a tmux pane rounds everything out. There is no context switch between my editor and my tools. If all my tools were GUI, It would be a cobbled together set of tools with an editor around it. If you were using an IDE suite and
No, you understand just fine. VIM has developed mostly irrational cult following. It exists because it came from an era when computer keyboards were not much more than typewriter keyboards. In that context you needed to get creative in order to interact with any software. I was building and messing with computers as far back as 1978, so yeah, I lived that era. And, yes, I too wrote editors and programs that operated in similar fashion. The motivation wasn't to make it more efficient or to keep your hands on the keyboard. The mouse did not exist. All you had was a crippled keyboard.
I don't know anyone of my generation that doesn't simply laugh or look at the cult of vim and isn't perplexed by some of what proponents of the cult say. We ran as fast as we could from those kinds of interfaces once the computer keyboard developed further and the GUI took to the world. The people who had to use that shit 'cause there was no other choice dropped it like hot potatoes as soon as they could.
Here's reality from the perspective of designing, building and programming all sorts of computers for over 30 years:
If you are spending so much time typing that fractions of a second at the keyboard make a significant impact on the development cycle, you are a hack and don't know what you are doing.
Real software and hardware engineers spend far more time designing and planning than coding. Coding is the end result of a process and, in terms of time, is often dwarfed by design and debugging.
As an example, we are in the middle of a month-long process of designing a database for a project. Not one line of code has been written. Every day is devoted to database structure discussions and documentation. Once settled, the DB code might take a week to write.
We are also designing an FPGA-based board as part of the same project. Over three months have gone into research, circuit design and other tasks. The time coding in Verilog won't even compare to the effort before getting to that point.
And then there's debugging and the inevitable pivot or two.
There's nothing whatsoever an editor can do to impact this development cycle in a measurable way. We use several GUI-based code editors. Nobody here is saying "if I could only keep my hands on the keyboard for another few seconds I could...". If they did, the laughter in the room would be so loud you could measure it with a seismograph because it is so utterly ridiculous.
Do I use vim? Of course, only when I have no other choice.
"Real software and hardware engineers spend far more time designing and planning than coding. Coding is the end result of a process and, in terms of time, is often dwarfed by design and debugging."
This part of your post is correct. If you don't spend much time coding then you don't have much reason to use Vim. ON the other hand, for those "fake" software guys who do spend a lot of time coding, especially editing code, then . . .
There have always been at least two camps in software development, and I'll throw in hardware in there due to FPGA's.
One goes to code right away and just hacks their way towards a solution.
The other camp is one where the problem is well understood first, design is done "on paper" and coding is simply the embodiment of that design process.
I say "on paper" because today it is likely to be a set of software tools such as state-machine editors, Excel, CAD, MATHLAB, etc.
It is my opinion that to write bug-free code that solves the problem efficiently, elegantly and as close as possible to on time and budget one has no choice but to design first and code as the end-result of the design process.
That's not to say that sometimes you need to write some test code as part of the design process in order to understand what might be going on. This happens a lot in embedded systems. Another scenario is web development where you need to interact with an API a bit before you can really understand how to work with it.
So I am not proposing not coding at all. What I am saying is that those code experiments are part of the "First Seek To Understand" rule (from "The 7 Habits...") that will make the project a success. The code experiments don't seek to solve the problem but rather add knowledge and understanding to the design process that will form the foundation for the actual solution.
If you are spending so much time typing that fractions of a second at the keyboard make a significant impact on the development cycle, you are a hack and don't know what you are doing.
This is a point addressed in the article.
And that’s why I don’t really care about Vim “speed”. I am not “faster” using Vim. I do not generate noticeable more code at the end of the day. But I generate it with less effort and caring more about the quality than battling with my keyboard. I am more relaxed, more in control, focused in what matters. Caring about getting stuff done. More productive. That’s Vim killer feature.
I think I can say with a good degree of certainty that the hundreds of editors I have used during my career so far, including vi, vim and some self-written, have been absolutely and utterly irrelevant to the success, failure, timeline or budget of any project I've ever done.
In case the question comes up. Why self-written editors? In the early days of using Forth to bootstrap embedded systems you pretty much had to write yourself a decent code editor to go with the system. I've never written an editor for other systems I've used. Whatever was available was always good enough.
> If you are spending so much time typing that fractions of a second at the keyboard make a significant impact on the development cycle, you are a hack and don't know what you are doing.
The win isn't that you saved fractions of a second. It's that your quick edit was fast enough that it didn't interrupt your thought process.
> As an example, we are in the middle of a month-long process of designing a database for a project. Not one line of code has been written. Every day is devoted to database structure discussions and documentation. Once settled, the DB code might take a week to write.
You say this like trial-and-error isn't a valid way to design something. You can spend as much time as you want designing things up front, but until you try them, there's a good chance you won't know if it's a good design. You'll always find issues later on.
Another way to look at it is this: you could write down you ideas on paper or in diagrams, or you could write them down in code, and run them to see if they make sense/work the way you think they should.
The code you write while designing doesn't have to be the same codebase as the final product. It can just be a bunch of small programs you use to help formulate your ideas.
Once you have enough experience you do far less trial and error. I rarely write code that does not work. By that I mean, my code generally solves the problem to be solved on the first write and is generally significantly bug-free.
That's not because I am a genius or somehow super-human, I have a lot of experience and have developed a decent process of design-before-coding. Trial and error is really wasteful. It still has it's place in areas that might not be entirely clear. Outside of that, design-before-coding can save tons of time and aggravation.
In other words, coding is the end of a process, not the process.
Ah, I think the difference is that usually when I'm working on something, it's a new problem, and I need some time to not only try to find a solution, but first understand the problem. I find that trying to write a solution helps me to get the problem space loaded into my head.
Different people have different processes, I suppose. And that's a probably a big reason for why people have different opinions on tools: they have different use cases.
The fact that you resort to attacking the messenger just furthers the idea that, for some, vim is an irrational cult, one that has never been shown to have a measurable impact on project performance from nearly any metric.
Look, I used vi for probably a decade while working on Silicon Graphics supercomputers and Sun workstation (Irix and Solaris). I know it pretty well. If I was maintaining Linux servers full time today there would be no question that vim would be the tool to use for obvious reasons. Beyond that...it has no impact on project performance.
To be totally clear, my position isn't that vim is useless. I never said that. What I am saying is that vim offers no advantage in the context of a non-trivial project when compared with GUI-based tools from Notepad++ on up. The design and debugging process offers far more significant gains than vim ever could. In fact, I'll go farther, I'll bet that solid documentation has a far greater effect in any project metric than the negligible gains ascribed to vim.
Want to use it? Fine. Your choice. Nothing wrong with that.
Your evaluation and thinking is entirely correct. For most mainstream development the vast majority of your time will be spent on things (debugging, testing, stepping through, reading documentation, refactoring, etc) that don't involve typing/modifying reams of text. Furthermore, if you're using languages like C++, Vim has very poor refactoring support when compared with commercial tools like Visual Assist. Having said that, you can get a decent IDE with Vim plugins - for free. You don't have to learn or use Vim's text manipulation commands at all, if you don't want to.
I think vim is especially well-suited to front-end dev, as it is one of the software areas that doesn't depend heavily on an IDE (as opposed to, say, Java). For me, vim keybindings are wired into my brain after a few years of use, and it lightens my cognitive load, just as it is stated in TFA. So, to answer your question:
> Why not just use a good, well-rounded editor like Sublime or Atom, or even Eclipse, for that matter..?
- Sublime: Closed-source.
- Eclipse: I don't need that big of an environment just for editing text.
- Atom: That one actually tempts me. I gave it a try, with the vim keybindings plugin, and it had a slight delay when executing commands that made me go away. I'm keeping a close eye on neovim integration, though; it sounds very promising.
It doesn't matter what type of dev you are front/back-end, Vim is (one) of the best text editors for coding period. I use it for both front and backend, and for note-taking when I'm doing UX design. Or when I'm writing blog posts. Or when I need to write a long email.
I also use Vim bindings in my browser thx to cVim.
>they might be great if you're doing scripting, messing around with the back end, or dong DB stuff. But for me, writing day-to-day JS, HTML, CSS code, VIM seems like a very huge burden.
Why is back-end different from front-end? It's all text on a screen. Your statement amounts to, "It might be good for writing and viewing text on a screen but for me, someone writing and viewing text on a screen, it seems like a burden."
VIM's (and others like it) strengths are in its configurability and movement commands and lack need for the arrow-keys. So much so that theres a VIM plugin for just about every popular editor, including Sublime and Atom.
I believe the need for fancier editors like Sublime and Atom has come about because VIM's development has waned and its code base is hard to update and innovate on.
Don't think of Vi or Vim as of regular editor. Think of it as functional programming language for text transformation, because that is what it essentially is. General form of vim command is nOm: repeat n-times operator O on text the motion command m moves over. So, for example, 5dw says "delete 5 words" because w command moves to next word, d operator stands "delete". The nice thing about this is that once you learn new motion command or operator, you become instantly more powerful. For example, after you learn that ) moves to the next sentence, you can now delete whole sentences with d). After you learn about change c operator, you can now change whole sentence with c). This essentially deletes the sentence and puts you in insert mode so you can type in the replacement text.
There are also text objects that allow you to apply operator on the object. For example if you are anywhere inside if (.) condition, you can type ci(, which stands for change inner ( i.e. change everything inside brackets, to quickly change the condition. Similarly, there is inner word, paragraph, XML tag, brace {, etc text objects, so it is fast to delete/modify etc entire blocks of code.
Vim also has Perl compatible regex engine, which allows you to do sweeping changes and transformation of text. The operators work with search motion as well, so you can do things like d/regex i.e. delete everything from current cursor position to first match of regex etc.
The :g ex command alone alows you to do fairly complex transformations, for example
:g/pattern/d
delete all lines that match pattern, or
:g/pattern/m$
move all lines matching a pattern to end of file, or something more complex:
:.,$g/^\d/exe "normal! \<C-A>"
Increment each number at the start of a line, from the current line to end-of-file, by one.
Of course there are a plethora of motion commands that allows you to quickly get to the line, character etc where you want to edit, all without taking your hand from the keyboard. In fact, most times you will be editing text well before the person using a mouse finds their mouse cursor.
This is all just scratching the surface (Vim has over 2000 commands), but hopefully it gives you the flavor of the experience editing in Vim. Getting proficient in Vim is liberating, it allows you to bend text effortlessly to your will without too much thinking really. It's programming your text, and in my mind a very valuable skill, just like learning the UNIX/POSIX command line is incredibly valuable (it's another functional programming environment where individual commands are your functions/filters and shell is executing them and you can string these filters together in unique ways to do all kinds of powerful things that simply don't have an equivalent in the GUI). Command line and Vim multiply you as developer and there is nothing in the GUI world that can come even close to this experience.
You can count me as one of those who simply don't like modal editors. Every vi(m) user has had the experience of pasting something in while in command mode or typing commands while in editing mode. It's disruptive and annoying (IMHO). Obviously YMMV.
But take the poster's example of changing parameters. Let me tell you how I do this in IntelliJ:
1. Click anywhere between the parentheses;
2. Press Ctrl+W (context-sensitive selection) repeatedly until I have everything within the parentheses;
3. Type the new parameters.
Now some might object to the mouse use here. There is a belief that the keyboard is faster, which seems to at least in part be an illusion [1]. Anyway, (1) can be replaced by any number of keyboard navigation techniques. Incremental search tends to be my "go to".
The one big use case for vim/emacs for me is the ability to use them over SSH. That's actually pretty huge but I won't use either all the time just for that.
At the end of the day vim (and emacs) are just text editors, which is fine, but you see this limitation all the time. Regex based syntax highlighting will have funny edge cases (emacs is a little different here I know).
An IDE is built to understand code constructs and concepts like the context-sensitive selection I mentioned above. Being able to move a java file and have it update all my imports and packages. Being able to auto import when I start typing a class name. Code templates (eg type "iter" or "itar" in IntelliJ then hit tab when you want to write a loop).
The amount of mental effort that seems to go into recreating an environment you get for free with an IDE is mind-boggling to me. By this I mean the constant tinkering with plugins and extensions.
Unfortunately many vim/emacs diehards use Eclipse as a strawman argument against IDEs ("I once used Eclipse and it was slow thus IDEs suck") when Eclipse is (IMHO) at best a medicore IDE with a lot of warts.
The other area where vim/emacs have survived is with the C/C++ family of languages (Visual Studio notwithstanding for Windows users). That's because tooling in this area has been pretty basic. I applaud Jetbrains' recent CLion effort.
The problem here is that the C++ grammar is so incredibly complicated it makes tooling difficult.
This is one reason why I appreciate the design goals of Go: simple grammar leads to easier tooling and faster compilation.
> An IDE is built to understand code constructs and concepts like the context-sensitive selection I mentioned above. Being able to move a java file and have it update all my imports and packages. Being able to auto import when I start typing a class name. Code templates (eg type "iter" or "itar" in IntelliJ then hit tab when you want to write a loop).
You can have the best of both worlds. For example, I use Visual Studio with the VsVim plugin. Visual Studio is my IDE, but vim is my editor.
while i use intellij, expand selection is available as a plugin for vim. i agree refactoring in a tool like vim is painful.
I also prefer integrated tooling like merge and git tools - both intellij and eclipse have great examples of these, rather than running 10 commands to replace 1 button click and pretending its the same thing.
i suppose my ideal company uses only typesafe languages so you can really ramp up your dev velocity with an ide - scala+scala.js or java+typescript for example.
personally I find intellij has better frontend plugins, but i honestly prefer the editing experience in java eclipse - too bad each editor in eclipse is its own experience.
I can't speak for CLion or the C++ plugin but in Java in IntelliJ you type:
switch (enumVar)
hit alt-enter and it gives you the option of filling in the missing branches. This even applies to partial switch statements missing some of the cases.
I know you mentioned 'some might object to the mouse use', but I would argue that a large number of people who prefer modal editors like Vi(m) do so because they can be driven completely by the keyboard and don't require you to use the mouse - which is disruptive and annoying (IMHO), obviously YMMV.
P.S. I gave you an upvote and I'm not sure why people were downvoting you. You presented clear and logical arguments for your opinion and even if I disagree with them, I can still respect them.
And you can enable mouse in vim if you really want. You can reproduce the 2nd point with ideavim's "ib" (inner block) selection (it's not the same though). So click -> ibc -> type your new thing > ESC .
> I know you mentioned 'some might object to the mouse use', but I would argue that a large number of people who prefer modal editors like Vi(m) do so because they can be driven completely by the keyboard and don't require you to use the mouse - which is disruptive and annoying (IMHO), obviously YMMV.
For some of us annoying is the least of the problem. Using the mouse to edit for more than an hour or two causes me crippling pain. Without Vim, or something else that would allow me to avoid the mouse 100%, I'm not sure I'd still be able to edit code at all.
Not every developer will develop RSI problems, but fewer would if they used a mouseless workflow.
which reminded me of another big thing I miss out on when using a text editor: navigate to superclass/declaration/implementation and "Find Usages" for a given function, class or variable.
Some things feel unnatural about vim. For instance I always tend to remap its default paste behavior to more commonly used one, and claims that one has to "adjust muscular memory" don't sound convincing to me when it introduces a drastic inconsistency.
Most editors paste text before the cursor position, and also set cursor position after the pasted text (after pasting). Vim defaults are different. If you press "p" it pastes after the cursor, and as well puts cursor on the last character of the pasted text (not after!). Vim offers an option that's similar to common behavior. It's "gP" (instead of "p"), so I usually remap p to act as gP, since that's what I use all the time:
noremap p gP
noremap P gp
noremap gp P
noremap gP p
Another thing that's commonly different in vim, is that when you select text in visual mode, it picks the character under cursor as well i.e. beyond the highlighted area. Most editors only select it until the cursor, and not including. Luckily this is also configurable with
set selection=exclusive
May be in vim it was always the other way for historic reasons, but consistency is convenient and at least in my case all other editors / text forms that I use (including browsers) act differently from vim defaults in regards to select / copy / paste behavior.
> claims that one has to "adjust muscular memory" don't sound convincing to me when it introduces a drastic inconsistency
Sorry, emacs user here... I just wanted to say that adjusting muscular memory can go faster than you expect. I learnt how to use emacs a couple of months ago, and have recently noticed the tendency to do ctrl-x + ctrl-s to save, or ctrl-y to paste, even when not in emacs ;-) The latter can be a bit annoying, but learning emacs was such a big plus that I don't mind much.
The article on vim sounds interesting, I tried and gave up learning it some time back, I should definitely revisit it again.
I don't mean you can't adjust muscular memory - you can. But when behavior is inconsistent (like pasting I described above), you need to switch it each time you use something that's not vim. For me it's not about what key combination to press - that's not as hard to switch, but more about what behavior to expect from the action "paste" and etc.
It takes too much thinking to use editors like that. I'm very much of the "don't make me think" school, and I grew up using Notepad. Well, maybe I don't use Notepad anymore, but I like it when I press the up-arrow key and my cursor moves up a line. Simple.
It seems to me that an approach like that won't advance you very far. There's a lot of work in software development that can reduced to nothing, if only you put the time up front to "think".
Whether or not the 10x developer is a myth, there are people who are vastly more productive than others. And they are people who have invested in themselves and their skills, automating away everything they possibly can.
For me it feels like I am pressing the up arrow key and the cursor is moving up, too. But really I am pressing a different key. Which key I no longer remember. If someone asks me, I have to retype it to check which key I have just pressed.
This is the reason people like Vim. Yes, there's an up-front learning curve, but it's not long until it's muscle memory. Now even complex editing tasks can be done without thought or effort.
It takes thinking to learn to use editors like this. Actually using them requires little to no thought after an acclimatisation period. This is one of the points of the article.
You're right it takes more thinking in order to learn vim or any set of key bindings. Vim has taught me that you are able to "speak", by typing, a language related to editing text. You are severely limiting your self in your efficiency of editing if you choose to ignore your ability to define macros/modes/whatever in a powerful text editor.
I use emacs now with a highly configured set of key bindings, and you're right it's taken me a lot of time. You're comment makes me think there are two types of programmers, those in the "don't make me think" school and those who spend an insane amount of time in one of the big editors, i.e vim/emacs/sublime. To make a gross example of the deficiencies of each, the "don't make me think" school are the people who would manually enumerate function calls instead of learning what a for loop is, while the crazy emacs hackers are the type to spend more time fine-tuning their config than actually working.
but I like it when I press the up-arrow key and my cursor moves up a line
I haven't used an install of Vim in a _long_ time that didn't map the arrow keys (and home, end, pgup, etc) to the way most modern computer users are used to.
I use Vim because it's what I learned when I first started using Unix/Linux. It's on just about every machine I work with and is easily installed on anything that doesn't come with it out of the box. I'm not arguing that it's the best ever editor, just that it works well for me.
But, yeah, the days of having to always use hjkl to move around are pretty deep in the past at this point.
While this is going to seem (and probably is) a bit inflammatory, I don't think any article will ever make a convincing Why Editor X Is Better argument for people who already use Editor Y.
In practice, there's a functionality bar for editors to clear; the likelihood that you're going to gain massive productivity improvements by switching between editors that are both past that bar is honestly pretty low. And that bar is likely lower than most people think. Reasonable syntax highlighting, good regex support in search/replace, some kind of "project" support, some kind of scriptability, and an ability to set basic editor configuration variables on a per language basis (e,g., 2-space tabs for YAML, 4-space for Python)... once you hit a certain point, then you get into progressively more dubious arguments. "I can change the contents between these parentheses on line 9 by simply typing '9Gf(ci(' while you're clicking in the line with your mouse like an animal!" Good for you, ace, but you're not really saving the time you think you are. (Also, you can perform a rough equivalent of "select or delete the stuff between these parentheses" with a single command in BBEdit, Sublime Text, and Emacs, and I'm sure in many other editors.)
I'm not suggesting all editors are absolutely fungible past a certain point -- there's solid reasons you may prefer one over the other -- but once you get really good with a given editor, "modality is awesome" and "everything in my editor is actually a Lisp command" shouldn't be particularly convincing arguments. Generally speaking, you probably have better things to do with your time than figure out how to replicate your favorite Editor X power moves in Editor Y. Don't you?
But can you repeat it in a slightly different place? That's where vim typically beats other editors for me. Every editor can do a one-off in some way. It's when you can repeat them in different contexts or quickly adapt them to slightly different ones. vim gives you tools right up front to do this quickly and accurately instead of doing repetitive mouse gestures or filling out dialogs.
I'm not sure that my interpretation of this is quite what you mean; most editor operations I do day to day, at least, aren't particularly context-sensitive. The balance command in BBEdit that I referred to above, for instance, just selects whatever's in between the closest pair of braces, brackets or parens, and if you keep hitting it, it expands the selection outward. There's not much I can think of that is context-sensitive other than functions relating to the language you're editing, and I can't think of any "class A" editors -- Vim, Emacs, Sublime, TextMate, BBEdit, etc. -- that seem way below (or way above) the median in this regard.
The debate about mouse-vs.-keyboard will probably be argued long after nobody's actually using either mice or keyboards. Personally I've found that the farther you need to move the cursor the more likely it is that using a pointing device for at least part of the operation will prove faster, and AFAIK most studies done on this going back 30+ years corroborate that, but it doesn't "feel" faster to us. (That's not directly relevant to editors, since Vim and Emacs both support mice just fine, even if their diehard fans consider that heretical.)
a) it has little to do with the tool itself (vim vs. whatever), it's about the payoff from investing time in learning an editor or environment well. once you know your tool well, friction drops substantially. if you take someone who knows something like intellij well and put them next to someone who knows vim well, it would probably be a wash in terms of who is hobbled most by the shortcomings of their tool. if you know a tool well, you know where it excels and where it sucks, and you have strategies for using it effectively.
b) to really know a tool well, a significant investment of time and effort must be made. i prefer to spend my time and effort on projects, to be honest.
c) vim is a tool that can be taken anywhere and the rewards of learning it can be paid back for years. corporate environment? usually already there or easy to get due to it being open source. platform? you can get it for pretty much any visual environment. language? if more than 10 people have written in it, there's a syntax colorizer for vim. need to do some ops stuff? vi will be there. hell, in a pinch, even busybox has a vi clone.
is it intrinsically better or worse? hard to say. but as far as i'm concerned, vim is a worthwhile investment because of its portability, longevity and constant adaption by a strong community to changing environments.
> it has little to do with the tool itself (vim vs. whatever)
I don't know about that. I've been proficient in other editors too, but I found that vim's modal editing mode confers unique advantages when it comes to staying in flow.
But if compared to an IDE there are several flow-breaking things in vim that just don't work as well out of the box (navigation, indexing, debugger integration etc), so if that's your point then I agree.
Of course most major IDEs have some sort of vim emulator these days so you can have your cake and eat it.
It's curious that vim uses modes and it is actually one of the things I really like about it. A lot of HCI talks about how modes are "evil" because the user can get confused and what mode they are in. I do occasionally issue a command from the wrong mode but I find that the time to correct is usually extremely small and far outweighs having to create more cumbersome bindings that don't have collisions in other modes.
The article is not about editor wars. The author only tries to make the point that how, after few years of use, the editor gets out of the way. It could as well be said about Emacs or maybe <insert your fav editor here>.
To me, the difference between using a command-driven tool and a graphical interface is comparable to the difference between explaining a native speaker how to get to the museum (straight-on for 200 m, second turn left, first turn right after the park) and trying to do the same to someone who does not understand any of the languages I speak by pointing, making walking movements with my hands, mimicking left and right-hand turns and trying to find a way to bring across the concept of a park by these means.
Yes, I had to learn German, English, Swedish and French before I could converse with people using those languages. This took time, but it was well worth the effort. It took time to learn (eg.) vi as well, but this too was worth the effort. I can still point and click my way through a maze of menus if I want by using a GUI-enabled version of vi or any other editor, but why bother when I can just tell the thing what I want in a few keystrokes?
I suppose you could use one of the thousands of GUI-based editors that also have key shortcuts for their commands. I don't know which one you used that required menu navigation to do everything you should name-and-shame so we know to avoid it.
Oh, I thought this was going to be about how fast "vim" runs. "vim" has performance good enough for looking at large text files such as logs in the 100MB range. Some editors will choke on that. Gedit on Linux blows up on excessively long lines, which is embarrassing for 2015.
I'm not going to read the article, and I'm not going to even say if I like VIM or not. I have become completely bored with the discussions about the pros and cons of VIM and other editors. My only hope is hundreds of years ago people were having the same discussions about pens versus pencils, and they were equally as bored with it as me.
I only comment because I care enough about any others out there, who may think they are all alone, who are as bored with this topic as I am.
I think the tool obsession blossoms with repetitive jobs. If you perform essentially the same programming task over and over, you focus on finding the most efficient way to do it. If your tasks are less repetitive, you probably spend more time thinking than writing code, so you are not as concerned with tool efficiency.
Car mechanics debate who makes the best 3/8" flex-head ratchet. Engine designers don't. [citation needed]
Still, the flex-head ratchet was probably invented by someone who got frustrated trying to turn a tricky bolt with a fixed-head ratchet. Discussing the benefits/limitations of current tools is worthwhile.
However, when it comes to text editors, I see a lot more "X editor is amazing, here's why" than I see "all editors are insufficient, here's how we should make them better."
I am not sure about "the tool obsession blossoms with repetitive jobs". Maybe my counter-example is very specific, but I think about painters (even on digital mediums) and the obsession about their tools.
1) You can use Ctrl-C instead of escape in most cases. This results in less travel distance and avoiding the wrist rotation. Which leads to...
2) Bind Caps Lock to Ctrl like God intended it to be. That way you can use Ctrl-C really easily and also the page navigation commands like Ctrl-(F|B|U|D) are really easy. This one might not work if you have a caps lock key with those weird notches.
3) Bind your Leader key to Space. I have the Unite plugin do fuzzy file / buffer finding when I hit Space Space.
4) Set up your own custom key bindings to the other Ctrl keys are aren't used by anything yet. Ctrl-S and Ctrl-V to split screens horizontally and veritcally.
A programming language / environment is at its best when it minimizes the amount of cognitive load and context switches. Mouse movements require a feedback loop where the user must lift their hand feel around for the mouse, then move the mouse, then there is a rapid loop where the user moves the mouse, sees where the cursor goes, determines how far from the destination it is, then repeat until the goal is reached.
Vim cursor movements however are more logical and absolute. Go up 2 lines, end of word, end of line, everything inside the quotes, etc. The cognitive load required is much less in vim -- at least once learned, but definitely not in the beginning when going through the learning curve.
It may not seem like much but every bit of brain power that can be freed up is that much more brain power that can be used to concentrate on the task at hand.
To someone who is trained in vim it just feels much more relaxed and fluid when editing. To exaggerate, imagine if every time you had to use the mouse, you had to open a drawer, pull out the mouse, plug it in, perform your action, then unplug it, then put it back into the desk. This is a contrived example for sure but it gives an illustration of the subtle distraction and annoyance many vim users feel when they have to use the mouse.
133 comments
[ 2.7 ms ] story [ 189 ms ] threadhttps://news.ycombinator.com/item?id=5448983
[1] http://allthingsergo.com/blog/wp-content/uploads/2011/08/gri...
My biggest issue other than that is the behavior of Shift doesn't match other keyboards :\ Can't shift click to select ranges of text.
316 Stainless Steel Precision Ball, 3/4" Diameter
Extreme-Temperature Slippery PTFE Ball, 1/8" Diameter
Hope that helps! I also tried the same stainless steel in 1/8", but that made the trackball loud.
http://www.reddit.com/r/MechanicalKeyboards/comments/2yfb7e/...
Don't get me wrong. I don't have anything against IDEs. I've been playing around with neovim's msgpack (the thing that would theoretically allow neovim to be embeded inside Intellij, for example) and if I get some time, I might start implementing an Intellij plugin to allow me to use neovim (ideavim is very buggy, unfortunately. I really appreaciate the author's effors, though, but the way to go in the long term is through neovim).
I use vim and git to manage my todo lists. I use vim to take meeting notes, and leverage pandoc to produce aesthetically pleasing pdfs to mail out. I use vim when writing my documentation in Markdown and/or reStructured Text. Vim is my default text editor for pretty much everything.
I just chose vim because I know it does let me move around without a mouse. I wouldn't mind using nano if it gave me the same thing vim gives me.
I prefer not using the mouse at all, and rarely do when I'm using emacs, but for any other apps and most websites it's unavoidable. The trackpoint is right there under my index finger and the mouse buttons convenient for thumbs. Far better than reaching for a mouse or even moving your hand down to a touchpad.
Lazy is preferring to move your hand over to the mouse instead of spending weeks learning an obscure editor called vim.
I have a beef with using the word "lazy" wrong like that. Lazy is undisciplined. The undisciplined will not become good programmers.
It takes a lot of discipline to learn vim.
It takes a lot of discipline to automate mundane operations.
My .vimrc now has "inoremap jj <Esc>" in it, and that was the final missing piece to get me into uninterrupted-productivity mode with Vim. Since you seem to have similar preferences, you might find that a useful optimization.
ETA: Apparently whoever I got this idea from got it from the Vim tips wiki. http://vim.wikia.com/wiki/Avoid_the_escape_key
Thank you for the tip anyway :-)
From that point you'll be constantly learning new ways of doing things better because vim is really more of a language than anything.
The biggest, easiest, thing for me was macros. Being able to easily and quickly record a macro and apply it over many lines - that's slick. Like converting a CREATE TABLE to a set of ORM instructions, or into a structure. Before I'd use some half cooked regex and clean up after. Now I just edit one l line while in a macro then run it N times.
Apart from that, it's just a ton of little things that add up.
Also: ViEmu for Office. VimFx for Firefox (there's one for Chrome too, Vimium). Browsing without the mouse is really great; quite elegant.
1: http://vim-adventures.com/
Nowadays when using vim I occasionally have people ask me "how did you do that?" and I won't even know what keys I typed. The keybindings are as natural as walking/grabbing things and require as much conscious thoughts. I usually have to redo it in slow motion to see what I did...
I can highly recommend Bram Moolenaar's essay on "The Seven Habits of Effective Text Editing" (http://www.moolenaar.net/habits.html), it has a vim focus, but I think his points are editor agnostic
Edit: I started using vim as a windows GUI person in university since I wanted to edit over SSH and vim was the only editor with syntax highlighting on the servers. So it's not like I was a terminal wizard back then (I am now :p)
I use VIM plugins heavily in Sublime (the Vintage plugin) and Android Studio.
> Try all the popular ones, give them all a fair shot like several weeks of exclusive use. Pick one. Practice it. Move on to more interesting problems.
Vim is a good well-rounded editor that can do anything Sublime or Atom can do. And it did them before Sublime or Atom existed. It has Gui's that feel native.
Every new generational crop of editors, I give the new guys a fair shot. Use them for a few weeks, but usually end up back on Vim after that. Last one that really "shook things up" was TextMate...though all editors have those features now.
So, to your question specifically: Why vim?
I could go on about keyboard efficiency or home row or more terse key combos to get the same thing done or blah blah blah. But really, none of that is true.
The reason I use vim is simple: It's feature full, does everything I need, I know it and know it well, and....
I've got better things to do then learn another editor as well.
Use whatever you like. It's about the code, not the editor.
Because those editors use GUI that isn't optimized for editing text. They use the same widgets that are used by the Volume Manager, the Finder, the web browser. Vim's interface is geared only towards editing text.
According to you VIM isn't optimized for editing text. It uses a UI (terminal) that was designed for entering batch commands and displaying their output.
I kind of felt the same way when I first started learning vim. It seems "foreign" at first, but now that I'm able to use it pretty proficiently I think this is a bad comparison.
Vim is more like a power screwdriver that not just anyone can handle, but once you get the hang of it you never want to use a regular screwdriver again.
Vim, unlike other editors, usually requires customization though, so you really have to emerge your self in vim to get up-and-running whereas with an editor like atom you're typically good to go.
I don't need any IDE fancy stuff when MVC is pretty straight forward.
If I need to split screen or jump between window it's tmux or vsplit/split on vim really. I don't use many commands with VIM.
Plus most front end tools are cmdline. bower, composer (for php), grunt, npm, etc... I also use vagrant to run my projects and ansible those are mostly cmdline.
I guess in general, I like the fact I have everything in control in one terminal.
I don't have to jump or juggle between different programs. IDE, Commandline, and bunch of other programs.
Some IDE might have bower, grunt, etc.. extension tuck in somewhere where I have to search for. No thanks.
I got tmux and I don't have to jump between window just to restart or do stuff with vagrant either.
edit: I know about 15 at max vim command. >___<. And like maybe 8 commands for tmux.
I'd like to ask you the same question: what makes you think Sublim or Atom is a superior text editor (not: I'm not talking IDE) ?
Personally I took the time to learn and be proficient with vim; it is now my editor of choice because it gives me a lot of power and doesn't get in the way. It did take time, but it was worth it. I'm pretty sure if I chose another editor I would be equally proficient; it's not so much about vim being the best one, it's more about how I'm efficient with it today.
I guess you've been turned down by vim because it's hard to start with, and in that sense Sublime or Atom are certainly better text editors ... but it doesn't matter, because the learning phase is only temporary.
What makes Vim NOT not a good, well-rounded editor in your opinion?
Comparing Vim to other text editors (sublime text, etc.) is a much more apt comparison.
Marks are powerful and play really well with all the movements like I'd expect them too...
Marks doesn't even have a visual indicator. So, somehow I doubt you're just using marks for bookmarking and vanilla syntax highlighting is pretty weak.
Let's see your list of plugins. I bet you have at least 30 of them.
Largest codebases I've worked with were upwards of 200k SLOC.
https://github.com/merijn/dotfiles/blob/master/install/vimpl...
I have 12, and most of them only have occasional/no use, but I haven't changed to remove them.
Coquille for working with Coq.
CtrlP for fuzzy opening of files.
Gundo for visually looking through vim's undo tree (I rarely use this, probably like once a month max, but it's very useful when I do need it)
My own haskell indenting plugin which is now disabled, because I'm too lazy to make it work like I need it too.
rainbow_parentheses highlights matching parentheses.
syntastic for highlighting compiler errors/warnings in files I'm editing.
tagbar, to be honest I actually never use this and should remove it.
vim-hdevtools lets me query the type of haskell expressions and show definitions of data types, although I mostly only use the type functionality.
vim-hoogle I never could be bothered to configure it, so it doesn't work and should be removed.
vim-pathogen for loading plugins.
vim-surround new movements for editing surrounding punctuation/html tags.
vimbufsync dependency of Coquille.
So, that's 9 plugins I actually use, one of which being a dependency.
It just depends where you start and are going.
I don't know anyone of my generation that doesn't simply laugh or look at the cult of vim and isn't perplexed by some of what proponents of the cult say. We ran as fast as we could from those kinds of interfaces once the computer keyboard developed further and the GUI took to the world. The people who had to use that shit 'cause there was no other choice dropped it like hot potatoes as soon as they could.
Here's reality from the perspective of designing, building and programming all sorts of computers for over 30 years:
If you are spending so much time typing that fractions of a second at the keyboard make a significant impact on the development cycle, you are a hack and don't know what you are doing.
Real software and hardware engineers spend far more time designing and planning than coding. Coding is the end result of a process and, in terms of time, is often dwarfed by design and debugging.
As an example, we are in the middle of a month-long process of designing a database for a project. Not one line of code has been written. Every day is devoted to database structure discussions and documentation. Once settled, the DB code might take a week to write.
We are also designing an FPGA-based board as part of the same project. Over three months have gone into research, circuit design and other tasks. The time coding in Verilog won't even compare to the effort before getting to that point.
And then there's debugging and the inevitable pivot or two.
There's nothing whatsoever an editor can do to impact this development cycle in a measurable way. We use several GUI-based code editors. Nobody here is saying "if I could only keep my hands on the keyboard for another few seconds I could...". If they did, the laughter in the room would be so loud you could measure it with a seismograph because it is so utterly ridiculous.
Do I use vim? Of course, only when I have no other choice.
This part of your post is correct. If you don't spend much time coding then you don't have much reason to use Vim. ON the other hand, for those "fake" software guys who do spend a lot of time coding, especially editing code, then . . .
One goes to code right away and just hacks their way towards a solution.
The other camp is one where the problem is well understood first, design is done "on paper" and coding is simply the embodiment of that design process.
I say "on paper" because today it is likely to be a set of software tools such as state-machine editors, Excel, CAD, MATHLAB, etc.
It is my opinion that to write bug-free code that solves the problem efficiently, elegantly and as close as possible to on time and budget one has no choice but to design first and code as the end-result of the design process.
That's not to say that sometimes you need to write some test code as part of the design process in order to understand what might be going on. This happens a lot in embedded systems. Another scenario is web development where you need to interact with an API a bit before you can really understand how to work with it.
So I am not proposing not coding at all. What I am saying is that those code experiments are part of the "First Seek To Understand" rule (from "The 7 Habits...") that will make the project a success. The code experiments don't seek to solve the problem but rather add knowledge and understanding to the design process that will form the foundation for the actual solution.
This is a point addressed in the article.
And that’s why I don’t really care about Vim “speed”. I am not “faster” using Vim. I do not generate noticeable more code at the end of the day. But I generate it with less effort and caring more about the quality than battling with my keyboard. I am more relaxed, more in control, focused in what matters. Caring about getting stuff done. More productive. That’s Vim killer feature.
In case the question comes up. Why self-written editors? In the early days of using Forth to bootstrap embedded systems you pretty much had to write yourself a decent code editor to go with the system. I've never written an editor for other systems I've used. Whatever was available was always good enough.
The win isn't that you saved fractions of a second. It's that your quick edit was fast enough that it didn't interrupt your thought process.
> As an example, we are in the middle of a month-long process of designing a database for a project. Not one line of code has been written. Every day is devoted to database structure discussions and documentation. Once settled, the DB code might take a week to write.
You say this like trial-and-error isn't a valid way to design something. You can spend as much time as you want designing things up front, but until you try them, there's a good chance you won't know if it's a good design. You'll always find issues later on.
Another way to look at it is this: you could write down you ideas on paper or in diagrams, or you could write them down in code, and run them to see if they make sense/work the way you think they should.
The code you write while designing doesn't have to be the same codebase as the final product. It can just be a bunch of small programs you use to help formulate your ideas.
That's not because I am a genius or somehow super-human, I have a lot of experience and have developed a decent process of design-before-coding. Trial and error is really wasteful. It still has it's place in areas that might not be entirely clear. Outside of that, design-before-coding can save tons of time and aggravation.
In other words, coding is the end of a process, not the process.
Different people have different processes, I suppose. And that's a probably a big reason for why people have different opinions on tools: they have different use cases.
I am very rational thank you very much. You don't know what you 're talking about.
Look, I used vi for probably a decade while working on Silicon Graphics supercomputers and Sun workstation (Irix and Solaris). I know it pretty well. If I was maintaining Linux servers full time today there would be no question that vim would be the tool to use for obvious reasons. Beyond that...it has no impact on project performance.
To be totally clear, my position isn't that vim is useless. I never said that. What I am saying is that vim offers no advantage in the context of a non-trivial project when compared with GUI-based tools from Notepad++ on up. The design and debugging process offers far more significant gains than vim ever could. In fact, I'll go farther, I'll bet that solid documentation has a far greater effect in any project metric than the negligible gains ascribed to vim.
Want to use it? Fine. Your choice. Nothing wrong with that.
> Why not just use a good, well-rounded editor like Sublime or Atom, or even Eclipse, for that matter..?
- Sublime: Closed-source. - Eclipse: I don't need that big of an environment just for editing text. - Atom: That one actually tempts me. I gave it a try, with the vim keybindings plugin, and it had a slight delay when executing commands that made me go away. I'm keeping a close eye on neovim integration, though; it sounds very promising.
I also use Vim bindings in my browser thx to cVim.
Why is back-end different from front-end? It's all text on a screen. Your statement amounts to, "It might be good for writing and viewing text on a screen but for me, someone writing and viewing text on a screen, it seems like a burden."
I believe the need for fancier editors like Sublime and Atom has come about because VIM's development has waned and its code base is hard to update and innovate on.
There are also text objects that allow you to apply operator on the object. For example if you are anywhere inside if (.) condition, you can type ci(, which stands for change inner ( i.e. change everything inside brackets, to quickly change the condition. Similarly, there is inner word, paragraph, XML tag, brace {, etc text objects, so it is fast to delete/modify etc entire blocks of code.
Vim also has Perl compatible regex engine, which allows you to do sweeping changes and transformation of text. The operators work with search motion as well, so you can do things like d/regex i.e. delete everything from current cursor position to first match of regex etc.
The :g ex command alone alows you to do fairly complex transformations, for example
delete all lines that match pattern, or move all lines matching a pattern to end of file, or something more complex: Increment each number at the start of a line, from the current line to end-of-file, by one.Of course there are a plethora of motion commands that allows you to quickly get to the line, character etc where you want to edit, all without taking your hand from the keyboard. In fact, most times you will be editing text well before the person using a mouse finds their mouse cursor.
This is all just scratching the surface (Vim has over 2000 commands), but hopefully it gives you the flavor of the experience editing in Vim. Getting proficient in Vim is liberating, it allows you to bend text effortlessly to your will without too much thinking really. It's programming your text, and in my mind a very valuable skill, just like learning the UNIX/POSIX command line is incredibly valuable (it's another functional programming environment where individual commands are your functions/filters and shell is executing them and you can string these filters together in unique ways to do all kinds of powerful things that simply don't have an equivalent in the GUI). Command line and Vim multiply you as developer and there is nothing in the GUI world that can come even close to this experience.
Vim is a good, well-rounded editor.
But take the poster's example of changing parameters. Let me tell you how I do this in IntelliJ:
1. Click anywhere between the parentheses; 2. Press Ctrl+W (context-sensitive selection) repeatedly until I have everything within the parentheses; 3. Type the new parameters.
Now some might object to the mouse use here. There is a belief that the keyboard is faster, which seems to at least in part be an illusion [1]. Anyway, (1) can be replaced by any number of keyboard navigation techniques. Incremental search tends to be my "go to".
The one big use case for vim/emacs for me is the ability to use them over SSH. That's actually pretty huge but I won't use either all the time just for that.
At the end of the day vim (and emacs) are just text editors, which is fine, but you see this limitation all the time. Regex based syntax highlighting will have funny edge cases (emacs is a little different here I know).
An IDE is built to understand code constructs and concepts like the context-sensitive selection I mentioned above. Being able to move a java file and have it update all my imports and packages. Being able to auto import when I start typing a class name. Code templates (eg type "iter" or "itar" in IntelliJ then hit tab when you want to write a loop).
The amount of mental effort that seems to go into recreating an environment you get for free with an IDE is mind-boggling to me. By this I mean the constant tinkering with plugins and extensions.
Unfortunately many vim/emacs diehards use Eclipse as a strawman argument against IDEs ("I once used Eclipse and it was slow thus IDEs suck") when Eclipse is (IMHO) at best a medicore IDE with a lot of warts.
The other area where vim/emacs have survived is with the C/C++ family of languages (Visual Studio notwithstanding for Windows users). That's because tooling in this area has been pretty basic. I applaud Jetbrains' recent CLion effort.
The problem here is that the C++ grammar is so incredibly complicated it makes tooling difficult.
This is one reason why I appreciate the design goals of Go: simple grammar leads to easier tooling and faster compilation.
[1]: http://ux.stackexchange.com/questions/30682/are-there-any-re...
You can have the best of both worlds. For example, I use Visual Studio with the VsVim plugin. Visual Studio is my IDE, but vim is my editor.
I also prefer integrated tooling like merge and git tools - both intellij and eclipse have great examples of these, rather than running 10 commands to replace 1 button click and pretending its the same thing.
i suppose my ideal company uses only typesafe languages so you can really ramp up your dev velocity with an ide - scala+scala.js or java+typescript for example.
personally I find intellij has better frontend plugins, but i honestly prefer the editing experience in java eclipse - too bad each editor in eclipse is its own experience.
I wouldn't choose my editor based on something that happens rarely and is merely "annoying."
One example (from C++, so maybe not relevant for IntelliJ) I use them for is converting enums to a case statement.
e.g. if I have:
I can copy/paste lines from VALUE_1 through to VALUE_10, and then start recording a macro as I change to Adding a final 'j' to move down a line before finishing the macro.Then I just run the macro several times and each line gets converted.
That's a pretty simple case (hah), there are plenty of other (and more complicated) uses for them too.
switch (enumVar)
hit alt-enter and it gives you the option of filling in the missing branches. This even applies to partial switch statements missing some of the cases.
>1. Click anywhere between the parentheses;
You lost me at step 1.
I know you mentioned 'some might object to the mouse use', but I would argue that a large number of people who prefer modal editors like Vi(m) do so because they can be driven completely by the keyboard and don't require you to use the mouse - which is disruptive and annoying (IMHO), obviously YMMV.
P.S. I gave you an upvote and I'm not sure why people were downvoting you. You presented clear and logical arguments for your opinion and even if I disagree with them, I can still respect them.
For some of us annoying is the least of the problem. Using the mouse to edit for more than an hour or two causes me crippling pain. Without Vim, or something else that would allow me to avoid the mouse 100%, I'm not sure I'd still be able to edit code at all.
Not every developer will develop RSI problems, but fewer would if they used a mouseless workflow.
https://www.jetbrains.com/idea/help/keyboard-shortcuts-and-m...
which reminded me of another big thing I miss out on when using a text editor: navigate to superclass/declaration/implementation and "Find Usages" for a given function, class or variable.
Most editors paste text before the cursor position, and also set cursor position after the pasted text (after pasting). Vim defaults are different. If you press "p" it pastes after the cursor, and as well puts cursor on the last character of the pasted text (not after!). Vim offers an option that's similar to common behavior. It's "gP" (instead of "p"), so I usually remap p to act as gP, since that's what I use all the time:
Another thing that's commonly different in vim, is that when you select text in visual mode, it picks the character under cursor as well i.e. beyond the highlighted area. Most editors only select it until the cursor, and not including. Luckily this is also configurable with May be in vim it was always the other way for historic reasons, but consistency is convenient and at least in my case all other editors / text forms that I use (including browsers) act differently from vim defaults in regards to select / copy / paste behavior.Sorry, emacs user here... I just wanted to say that adjusting muscular memory can go faster than you expect. I learnt how to use emacs a couple of months ago, and have recently noticed the tendency to do ctrl-x + ctrl-s to save, or ctrl-y to paste, even when not in emacs ;-) The latter can be a bit annoying, but learning emacs was such a big plus that I don't mind much.
The article on vim sounds interesting, I tried and gave up learning it some time back, I should definitely revisit it again.
Whether or not the 10x developer is a myth, there are people who are vastly more productive than others. And they are people who have invested in themselves and their skills, automating away everything they possibly can.
After some time, it all become muscle memory.
I use emacs now with a highly configured set of key bindings, and you're right it's taken me a lot of time. You're comment makes me think there are two types of programmers, those in the "don't make me think" school and those who spend an insane amount of time in one of the big editors, i.e vim/emacs/sublime. To make a gross example of the deficiencies of each, the "don't make me think" school are the people who would manually enumerate function calls instead of learning what a for loop is, while the crazy emacs hackers are the type to spend more time fine-tuning their config than actually working.
I haven't used an install of Vim in a _long_ time that didn't map the arrow keys (and home, end, pgup, etc) to the way most modern computer users are used to.
I use Vim because it's what I learned when I first started using Unix/Linux. It's on just about every machine I work with and is easily installed on anything that doesn't come with it out of the box. I'm not arguing that it's the best ever editor, just that it works well for me.
But, yeah, the days of having to always use hjkl to move around are pretty deep in the past at this point.
In practice, there's a functionality bar for editors to clear; the likelihood that you're going to gain massive productivity improvements by switching between editors that are both past that bar is honestly pretty low. And that bar is likely lower than most people think. Reasonable syntax highlighting, good regex support in search/replace, some kind of "project" support, some kind of scriptability, and an ability to set basic editor configuration variables on a per language basis (e,g., 2-space tabs for YAML, 4-space for Python)... once you hit a certain point, then you get into progressively more dubious arguments. "I can change the contents between these parentheses on line 9 by simply typing '9Gf(ci(' while you're clicking in the line with your mouse like an animal!" Good for you, ace, but you're not really saving the time you think you are. (Also, you can perform a rough equivalent of "select or delete the stuff between these parentheses" with a single command in BBEdit, Sublime Text, and Emacs, and I'm sure in many other editors.)
I'm not suggesting all editors are absolutely fungible past a certain point -- there's solid reasons you may prefer one over the other -- but once you get really good with a given editor, "modality is awesome" and "everything in my editor is actually a Lisp command" shouldn't be particularly convincing arguments. Generally speaking, you probably have better things to do with your time than figure out how to replicate your favorite Editor X power moves in Editor Y. Don't you?
The debate about mouse-vs.-keyboard will probably be argued long after nobody's actually using either mice or keyboards. Personally I've found that the farther you need to move the cursor the more likely it is that using a pointing device for at least part of the operation will prove faster, and AFAIK most studies done on this going back 30+ years corroborate that, but it doesn't "feel" faster to us. (That's not directly relevant to editors, since Vim and Emacs both support mice just fine, even if their diehard fans consider that heretical.)
a) it has little to do with the tool itself (vim vs. whatever), it's about the payoff from investing time in learning an editor or environment well. once you know your tool well, friction drops substantially. if you take someone who knows something like intellij well and put them next to someone who knows vim well, it would probably be a wash in terms of who is hobbled most by the shortcomings of their tool. if you know a tool well, you know where it excels and where it sucks, and you have strategies for using it effectively.
b) to really know a tool well, a significant investment of time and effort must be made. i prefer to spend my time and effort on projects, to be honest.
c) vim is a tool that can be taken anywhere and the rewards of learning it can be paid back for years. corporate environment? usually already there or easy to get due to it being open source. platform? you can get it for pretty much any visual environment. language? if more than 10 people have written in it, there's a syntax colorizer for vim. need to do some ops stuff? vi will be there. hell, in a pinch, even busybox has a vi clone.
is it intrinsically better or worse? hard to say. but as far as i'm concerned, vim is a worthwhile investment because of its portability, longevity and constant adaption by a strong community to changing environments.
And just for the sake of having mentioned it, ed is still the standard text editor!
I don't know about that. I've been proficient in other editors too, but I found that vim's modal editing mode confers unique advantages when it comes to staying in flow.
But if compared to an IDE there are several flow-breaking things in vim that just don't work as well out of the box (navigation, indexing, debugger integration etc), so if that's your point then I agree.
Of course most major IDEs have some sort of vim emulator these days so you can have your cake and eat it.
Yes, I had to learn German, English, Swedish and French before I could converse with people using those languages. This took time, but it was well worth the effort. It took time to learn (eg.) vi as well, but this too was worth the effort. I can still point and click my way through a maze of menus if I want by using a GUI-enabled version of vi or any other editor, but why bother when I can just tell the thing what I want in a few keystrokes?
Car mechanics debate who makes the best 3/8" flex-head ratchet. Engine designers don't. [citation needed]
Still, the flex-head ratchet was probably invented by someone who got frustrated trying to turn a tricky bolt with a fixed-head ratchet. Discussing the benefits/limitations of current tools is worthwhile.
However, when it comes to text editors, I see a lot more "X editor is amazing, here's why" than I see "all editors are insufficient, here's how we should make them better."
1) You can use Ctrl-C instead of escape in most cases. This results in less travel distance and avoiding the wrist rotation. Which leads to...
2) Bind Caps Lock to Ctrl like God intended it to be. That way you can use Ctrl-C really easily and also the page navigation commands like Ctrl-(F|B|U|D) are really easy. This one might not work if you have a caps lock key with those weird notches.
3) Bind your Leader key to Space. I have the Unite plugin do fuzzy file / buffer finding when I hit Space Space.
4) Set up your own custom key bindings to the other Ctrl keys are aren't used by anything yet. Ctrl-S and Ctrl-V to split screens horizontally and veritcally.
5) Bind Ctrl-(H|J|K|L) to move between screens.
Vim cursor movements however are more logical and absolute. Go up 2 lines, end of word, end of line, everything inside the quotes, etc. The cognitive load required is much less in vim -- at least once learned, but definitely not in the beginning when going through the learning curve.
It may not seem like much but every bit of brain power that can be freed up is that much more brain power that can be used to concentrate on the task at hand.
To someone who is trained in vim it just feels much more relaxed and fluid when editing. To exaggerate, imagine if every time you had to use the mouse, you had to open a drawer, pull out the mouse, plug it in, perform your action, then unplug it, then put it back into the desk. This is a contrived example for sure but it gives an illustration of the subtle distraction and annoyance many vim users feel when they have to use the mouse.
http://vimcasts.org/episodes/selecting-columns-with-visual-b...
But yes, you need to know your shortcuts.