> 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.
> 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 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.
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.
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.
:h mark
>syntax highlighting :h syntax
>collapsible sections :h folds
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.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.
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 use VIM plugins heavily in Sublime (the Vintage plugin) and Android Studio.
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.
Vim is a good, well-rounded editor.
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.
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)
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.