I basically started learning Vim because.. well it was a hipster thing. The first two years, I really did not know how to actually learn it. All I would do is enter insert mode, move around with arrows and ":wq". But then after 6 months, I started with basic commands, like "55gg" to move to the 55th line etc, "G" to the last line and "gg" to the first line. Then came buffers, I started opening multiple files and started using minibufexplorer(my entry point into plugins). This went on for another 6 months. Next came actions and boy oh boy, I became the hipster vim user in college. While editing CSV files(like deleting all instances of a particular row having text "abc"), I used Vim instead of awk/sed just because I wanted to learn more. Fast forward a year, I call myself a basic vimmer and superior to others at my workplace by just knowing search, moving around, actions, buffers, a cool autocomplete plugin and other plugins here and there.
Throughout the learning process one thing I observed was that, its just not enough to read about a cool article about Vim and leave it there. I would keep repeating the sequence of actions mentioned in the article atleast ten times every day and would find some usage for it during programming. I would intentionally force myself to use it, until at some point, the action I just learnt magically comes in as a replacement for a dumb action I was about to do. At that point I would know I've mastered it.
I'm still stuck in the first step because I have simply no interest in learning vim. I only know a small subset of commands.
No I feel a bit like missing out.
I'm guessing a small subset of commands is about all that many productive Vim users know. You don't have to know everything to make good use of the tool.
Frankly I find vim an hindrance to the type of projects I work on.
One of the most common things I use an IDE for is navigation (between files) and vim is not very good at it compared to IDEs, here's why:
* no tabs
* no project structure
* in my IDE (eclipse based or intellij based) I can ctrl-click a class/object/other to navigate into that object's definition
* in my IDE I can search for classnames, I can press ctrl-T to find who inherits from something, ctrl-alt-H to find who uses something etc...
when I find myself actually writing code, it's usually a line or two in each of several files (because modern programming paradigms tell us we should split code as much as possible), or modifying some copy pasted snippet I found on google - so navigation is extremely important even when editing.
beyond that, there are simply some things that help writing code that a text editor cannot do:
* auto-complete(with annotation to tell you what the function variables are)
* debug inside your IDE
* run code-lint, auto-build on typing to detect errors, etc...
* auto refactor (I.E. extract method, move variable, extract class etc...)
* format all your files according to your pre-specified project guideline.
* sharing you IDE configuration with other contributors
* showing when files are/aren't in version control and integrating version control so that you view history in your IDE.
There are probably projects out there where a full-featured text editor is a real game-changer and is worth the days/weeks it'll take to use it intuitively, but I never worked or know anyone who worked on such a project (even when I started projects from scratch);
Eh, half of this list actually IS possible with Vim, either through a plugin or simply out-of-the-box keyboard shortcuts. The other half are features that separate IDE's from text editors in general.
I do agree that I'm infinitely more productive in an IDE than I ever would be with any plain text editor (e.g. autocomplete-hints, refactoring support, etc etc). After discovering the JetBrains suite of IDE's some years ago, I can't imagine using anything else for application development.
However, the point of vi/Vim is not so much the editor application itself... but rather its keybindings and modal editing approach in the abstract. Those concepts are decoupled from the actual editor, because every major IDE has plugins which make them available in its environment as well. The "IdeaVim" plugin for JetBrains IDE's is amazing, letting you mix-and-match between Vim commands and normal JetBrains shortcuts in a very intuitive way (or at least intuitive if you're familiar with Vim).
If you're happy with your current working environment, then rock on. But if you're fluent with vi/Vim (and it is a significant learning curve), then you can absolutely have the best of both worlds. To me, arguing about whether to use an IDE or an editor is pretty silly. But the question of whether or not to use modal editing and a suite of standard shortcut commands within an IDE is a much more interesting matter.
My biggest problem with vim is that I can get it configured with all of the plugins to emulate a GUI IDE, but it does nothing to help if I can't remember the shortcuts. Off by one character? Whoops, you activated the RootNuker Plugin on Buffer 3. Discoverability is terrible, one of the few things that I feel is actually faster with a mouse.
There's no doubt, vim isn't big on making it easy to find your way around.
I don't think that matters so long as you're methodical in your approach to learning it. It's important to master the basics and then add new tools one at a time.
The amazing thing about vim is that each new command can be composed with your existing knowledge set, so just learning what, say, 's' does gives you a whole lot more power.
Also, while the discoverability might suck, the built in manual is just incredible.
This doesn't apply to plugins however, which constitute most of what would make Vim an IDE. Most of the core commands are pretty well thought out and I have a nice keyboard map printed out just in case.
Absolutely. That said, I think modern IDEs suffer from huge discoverability problems as well. The truth is, when you have thousands of features, discoverability had to give way to documentation.
I think the major benefit I derive from what I mentioned is the constant visual cues and the immediate availability.
With buffers (unless I'm missing something) you need to type a command to list all your 'tabs' and another command to get to the tab in question.
Project structure is similar - it's always visible, and you can always see what other files are close by.
I don't think that can be achieved with plugins, though I never knew there were plugins until now.
Do people who use vim regularly install plugins for it?
A nice configuration for Haskell which I often use to bootstrap new machines is haskell-vim-now(https://github.com/begriffs/haskell-vim-now). That includes almost all the features you mention.
I read that StackOverflow answer before and given the amount of upvotes it
received, I presumed that it had something going for it.
I was already regularly comfortably using `Ctrl-^` to switch back and forth
between the current and alternate buffers but I was also used to having
different buffers open in different tabs and selecting them using either the
`gt` family of commands or the `:tabfirst` family.
I like having the tab-bar provide visual cues for each of the buffers that I’m
working with rather than having to type `:ls` to see the list of buffers
(which can sometimes be very large as I often leave Vim running for a long
time and if I do close, I usually restore it from a session).
Like you, I’ve yet to encounter any problems with this way of working. It’s
possibly because I’ve never used any commands which utilise the quickfix
buffer (`:make`, `:grep`, and `:helpgrep`) but maybe, there’s something else
I’m missing?
Yes, I'd wager that regular Vim users employ a variety of plugins. Vim is a powerful editor out of the box, but it falls short of many IDE capabilities without leveraging plugins.
There are many packages on GitHub that will install and configure Vim for you with a variety of useful plugins and keyboard shortcuts out of the box--so after the installation is complete, you'll have a fully fledged Vim IDE ready to use.
One of my favorites is Joe Nelson's setup [0]. It's specific to Haskell development, but even if that's not relevant to your use-case, it's a very sleek demonstration of what Vim can do as an IDE--and a good starting point for customizing your setup (i.e. a very clean .vimrc file for inspiration). I use it basically as-is for my default Vim config and as a full IDE. Check out the keyboard shortcuts for quickly switching buffers, Git integration, and the shortcuts for visualizing project structure & quickly navigating files.
-> multiple vim plugins provide really confortable tabs.
* No project structure.
-> plugin. if you want that kind of tree next to your editor. (i.e. Nerdtree)
* in my IDE (eclipse based or intellij based) I can ctrl-click a class/object/other to navigate into that object's definition
-> tag search plugin. Haven't played with it much though.
* in my IDE I can search for classnames, I can press ctrl-T to find who inherits from something, ctrl-alt-H to find who uses something etc...
-> I believe there are some plugins for but here i haven't seen anything good so far.
* auto-complete(with annotation to tell you what the function variables are)
-> you complete me. plugin.
* debug inside your IDE
-> good point. have to wait for Neovim for this - I believe. Installing current WIP version from neovim is on my todolist. ;)
* run code-lint, auto-build on typing to detect errors, etc...
-> syntastic.
* auto refactor (I.E. extract method, move variable, extract class etc...)
-> good point. don't know any good plugin.
* format all your files according to your pre-specified project guideline.
-> plugin.;)
* sharing you IDE configuration with other contributors
-> here truly most IDEs suck. For vim you find lots of shared vimconfig on github.
* showing when files are/aren't in version control and integrating version control so that you view history in your IDE.
-> if you need to do in the editor... there is plugin for that. However, i found git command line is usually find. and for more serious committing I use GitX (L).
> * in my IDE I can search for classnames, I can press ctrl-T to find who inherits from something, ctrl-alt-H to find who uses something etc...
>> -> I believe there are some plugins for but here i haven't seen anything good so far.
Language dependent, Go has "Oracle" for example, for finding callers, etc.
> * debug inside your IDE
>> -> good point. have to wait for Neovim for this - I believe. Installing current WIP version from neovim is on my todolist. ;)
Clewn.
> * auto refactor (I.E. extract method, move variable, extract class etc...)
>> -> good point. don't know any good plugin.
Language specific, Go has multiple and lots of people write small bits of script to do this -- but it is a place IDEs are far ahead of Vim.
> * showing when files are/aren't in version control and integrating version control so that you view history in your IDE.
>> -> if you need to do in the editor... there is plugin for that. However, i found git command line is usually find. and for more serious committing I use GitX (L).
In my view, Vim is no longer just a program that people use, but a way to do things. In this view, I am hopeful for the NeoVim project to bring Vim-the-way to other editors, including your favorite IDE.
One of my pains was that Vim-the-program was not ready to go, and that configuring or adding plugins to Vim was a real nuisance, and I think due to terminal limitations, Vim-the-program could never have some of the features other programs had.
-No project structure? Well, there is nerdtree. Or a separate terminal window open to the file system which is usually the way I do it.
-Autocomplete with annotation? Nice plugin for that.
-Debug? I'm running in separate terminal window anyway. I can debug there.
-Auto refactor? No thanks. I'd rather do that myself.
-Format according to guidlines? There is probably a plugin, but for the once or twice that happens third party tools work just fine. Don't need that in the editor.
-Sharing your configuration? Very easy. Just copy your .vim and .vimrc files over.
-Showing files in that aren't in version control? Remember my separate terminal window that's open? I don't want everything in the editor. But there is probably a plugin if you really need it.
____________
Here are the advantages: Cost, Ubiquity, works over SSH the same way. Takes two seconds to move my config files and I'm right back in the environment. Plus I know it and it is fast as heck. There probably some others I'm forgetting.
Honestly, it sounds like you haven't taken the time to get to know Vim. And that's ok... if you have something that work for you then no need. But lots of the things you claim are advantages of your setup really aren't.
It becomes a lot harder to switch programming languages and tools once you are dependent on some of these IDE features. Switching from using Eclipse for Java to using Closure without quite the tooling you've had before could be pretty hard if you join a new team.
I recently started using IntelliJ, and at install it suggested using the vim emulator. Being able to use vim shortcuts together with IntelliJ features has been one of my best editing experiences to date.
There have been a lot of replies addressing a few of your concerns, I will attempt to hit all of them. The only one that really has any no great solution is the refactoring support.
> * no tabs
There actually are tabs, but they probably don't work the way you expect, they are closer to viewports or workspaces, but they are there. You can also use assorted plugins to improve tabs and/or emulate them.
> * no project structure
Not sure I understand this way -- no enforced structure? Neither to IDEs, no tree viewer -- there are bunches of tree based file viewers.
> * in my IDE (eclipse based or intellij based) I can ctrl-click a class/object/other to navigate into that object's definition
This is supported by the tags system in Vim, which depends on ctags. :tselect, C-], lots more -- this exists out of the box.
> * in my IDE I can search for classnames, I can press ctrl-T to find who inherits from something, ctrl-alt-H to find who uses something etc...
This obviously very specific to some language you have in your head, as many of those things don't make sense in some languages. That said, this is supported in various languages by various plugins (In Go, Oracle for example).
> when I find myself actually writing code, it's usually a line or two in each of several files (because modern programming paradigms tell us we should split code as much as possible), or modifying some copy pasted snippet I found on google - so navigation is extremely important even when editing.
Agreed, which is why Vim has so many ways from jump-to-def to jump-to-file to various smart plugins for rails and C and <X>.
> * auto-complete(with annotation to tell you what the function variables are)
Gobs of plugins do this for Vim -- normally language specific and they tend to work rather great.
> * debug inside your IDE
See Clewn, full gdb support integrated with vim.
> * run code-lint, auto-build on typing to detect errors, etc...
Vim has all of that, syntastic will show errors in the left bar as you type, setting things to autorun is trivial, all major languages already have this.
> * auto refactor (I.E. extract method, move variable, extract class etc...)
Language specific (as is your IDE's features, because to do requires understand the language), but this exists in limited form for Go and C++ -- and I am sure others. The level isn't up to major IDEs. That said, many of these things are easily scriptable in vim.
> * format all your files according to your pre-specified project guideline.
Tons of vim support for this, even supporting standard 3rd party like EditorConfig.
> * sharing you IDE configuration with other contributors
I think you will find far more vimrc files shared in the wild than any IDE.
> * showing when files are/aren't in version control and integrating version control so that you view history in your IDE.
Fugitive has great time travel features for flipping through versions of files and seeing differences. Use git-nerdtree to add git status to nerdtree.
Yes, there are definite reasons why the vi/vim editing model is just superior to any other out there
Zealots trying to convert unbelievers is plain obnoxious. Your choice of editor isn't a religion so use what you use and I'll use what I use and you don't have to worry that what I'm using isn't what you are.
I'm having a hard time drawing a connection between the quoted text and your reaction.
The author believes that <Technology X> is superior to the alternatives, and wrote a blog post complaining about people who pressure its users to switch away. That's not exactly Jehovah's Witness knocking on your front door to thrust a magazine in your hand. In fact, the conclusion section starts with, "Do whatever you want. Don't learn it if you feel it's too much effort just for nothing.". The gist of this piece doesn't seem to be "converting" anyone. Ironically, it seems to have been inspired by receiving such pressure from others.
Half of Hacker News consists of discussing why all users of last week's fad should abandon it and jump onto this week's fad (e.g. "MySql -> Postgres -> MongoDB -> back to Postgres"... "Ruby -> Scala -> Node -> Go -> Rust -> Julia", etc). If you're looking for obnoxious zealotry, there are plenty of better threads in which to look.
Probably it's just driven by the use cases: most vi users (probably) come from server side, where you don't have a mouse.
Vi is particularly effective in those circumstances
Well good for you! I am impressed seriously! It is 2015 and arguments like "we don't need no stinking mice" are still used to defend vi. If all that effort was put into building a better shell that works with a mouse (or trackpad if you use them apples), where would we be right now?
> If all that effort was put into building a better shell that works with a mouse (or trackpad if you use them apples), where would we be right now?
You are missing the very point of a shell. Text gives you power, composability and flexibility that you simply cannot achieve with a GUI. Automation becomes extremely easy because of this.
Editing text without having to move your hands back and forth between keyboard and mouse makes it so much faster and lets you concentrate on your actual work instead of breaking your concentration.
Vim has its own vocabulary, and the essence of vim commands is composability. You imbibe this vocabulary over time and editing text becomes effortless like stringing together words to form sentences and sentences to form paragraphs.
The shell is so successful precisely because it uses text as a common representation for all data. It simply wouldn't work with a mouse. Many people have tried this and failed.
Computers are good at manipulating text and humans are good at understanding text. The abstract geometry that you have to use to describe mouse movements is neither intuitive, nor is it easy to process.
> Text gives you power, composability and flexibility that you simply cannot achieve with a GUI.
Can you think of any big things that you lose though?
> Editing text without having to move your hands back and forth between keyboard and mouse makes it so much faster and lets you concentrate on your actual work...
I could probably get between floors in my house an order of magnitude faster if I replaced the stair cases with slides and a trampolines. Somehow, that does not seem practical though.
> The shell is so successful precisely because it uses text as a common representation for all data.
Successful in what way? As successful as GUIs?
> Computers are good at manipulating text and humans are good at understanding text.
Humans are good at understanding patterns and symbols and they're not good at memorizing text commands. That's why everybody can use GUIs but few can use a shell.
They each have pros and cons. GUIs are generally more discoverable. Terminals are /way/ more flexible, faster, and customizable if that's your job and you take the time to learn them.
> Can you think of any big things that you lose though?
Definitely. Customizing behaviors. I work with image sequences a lot. "ls" is used to list files in a directory "lss" is a command we wrote to group image sequences together. This makes finding missing images in a sequence, knowing the range, and dealing with 1000's of files in a folder trivial. These are technically possible with a gui, you need to re-write your whole file-browser or have one with some plugin system that support this (I don't know of any).
> I could probably get between floors in my house an order of magnitude faster if I replaced the stair cases with slides and a trampolines. Somehow, that does not seem practical though.
That's a terrible analogy and a half-truth on both sides. Jumping to the mouse does slow things down, but I use GUI file browsers without a mouse just fine. The only thing I can't do out of the box is resize and move windows around--navigating through directories is fine.
> Humans are good at understanding patterns and symbols and they're not good at memorizing text commands. That's why everybody can use GUIs but few can use a shell.
I think the difference is that guis offer more spacial queues and persistent information than terminals do. Someone who has never used a computer would be equally confused at how a mouse or scrolling worked. Humans are not terrible as memorizing text commands, there's just no need to use them everyday and a gui is usually good enough. Fewer people can drive a stick-shift or parallel park now that it's generally unnecessary. It's not that it was difficult. I imagine in a few generations after automation takes off driving a car at all will be difficult for most people.
Ahh, these responses... (This space reserved for further passive aggressive comments.)
You didn't say how you arrived at the conclusion that shells are "so successful". How are you measuring that?
> ...a command we wrote to group image sequences together. This makes finding missing images in a sequence, knowing the range, and dealing with 1000's of files in a folder trivial. These are technically possible with a gui...
Those things are eminently possible with a GUI without writing your own file browser since most major file browsers offer a range of extensibility options. Also, GUI automation is a thing and it works well. Just last month I wrote a simple script to automate image extraction from a program that didn't provide any API for it. As a matter of fact, I didn't even have to write most of the script because the computer aided me by recording my mouse clicks.
> Jumping to the mouse does slow things down.
Looking up commands and configuration protocols slows things down way more though.
> Someone who has never used a computer would be equally confused at how a mouse or scrolling worked.
Equally as confused as they'd be when presented with nothing more than a blinking cursor? I don't think so... Once you move the mouse and see the pointer move, it's pretty obvious how movement works. Sixty seconds is enough time to accurately convey complete operating instructions for a mouse. Teaching someone how to use a shell would take much more time I imagine.
Anyway, I use a shell when it suits me and a GUI when that suits me, but most importantly, I am not a bigot or an elitist about it. I don't think that there is one true way to do things.
"Ahh, these arguments." was actually intended for both sides (gui and cli) since I don't particularly care which people prefer. Like I said, they both have pros and cons.
It hasn't been explicitly said, but all of these arguments are implicitly about file browsing and file management. I can't imagine anyone exclusively using commandline tools for things like audio editing, browsing the web, etc.
I'm genuinely interested, how would you write something like that for a file browser on any platform?
> ...how would you write something like that for a file browser...
A GUI program can do everything that a command line app can do and more, but unless we discuss exact requirements I can't answer the question very precisely. In terms of input and output I think there are generally more options with a GUI though.
Funny story on this topic - last night I was playing around with Fedora 21 + Gnome 3 and when I used git (in a terminal), whenever it needed a username or password it would pop up a GUI with a single text input. It's called askpass and I still haven't found out what exactly necessitates such a workflow, but I thought it was pretty hilarious.
> ...on any platform.
Command line programs don't work on every platform. Far from it. They don't even work on every Linux distro and especially not with normal usage on variants such as Android. So that's a bit of an unfair requirement to add just for GUI apps, don't you think?
I think we're in agreement that they both have pros and cons. It certainly can be easier to write a command line application that works on all platforms. I wasn't arguing against that - I was arguing with the guy on this thread who seemed to think that command lines are the single best way to interface with the computer. The guy who responded to almost every dissenting point of view...(not you). I didn't realize that it was not you at first, but my first response was to that person.
By any platform I meant "a platform of your choice." Like I mentioned in my first reply, I'm not aware of any OS's file browser with a plugin system to do something like what I described in any scope. I'm curious the tools someone who had their choice would gravitate to.
There are a lot of things I like with a terminal; history, tab completion, man pages (all OS help pages are generally useless. The only aspect I've ever liked is OSX's searchable help menu that will hightlight menu options). On the gui end you can't beat the discoverability, window management, but a big win is an undo stack. I feel like touchscreens are a step back in discoverability (but they have their own merits).
I think terminal people really latch on to the composibility of Unix apps that are provided via pipes. I've seen people try to come up with a gui equivalent (copy/paste is the closest), each gui feels like a walled garden (almost as bad as iOS apps). Something like AppleScript or D-Bus tries to address this, but I feel like if you're writing a script its basically a less-interactive shell. Automator seems like a decent take on this, but not too many apps expose an api for that and I've struggled trying to get it do what I wanted.
Just one question regarding the program you described - you're talking about the "lss" command you wrote, correct? You said that it exists in order to "group image sequences together. This makes finding missing images in a sequence, knowing the range, and dealing with 1000's of files in a folder trivial".
I don't know how you're grouping image sequences together, but I can't imagine why a GUI wouldn't be able to represent image groups as well as or better than a terminal program. Could you tell me? Alternatively, is your program open source? I'd love to check it out.
Each application and vfx studio has their own conventions for notating a group of images (if they're zero-padded, if they're only even numbers, etc). Most of the File Open dialogs for these apps implemented their own grouping. I've never seen a general gui file browser version of this.
> I've never seen a general gui file browser version of this.
The hooks are there to do it though, at least in Windows Explorer and Gnome/Nautilus. Something very similar built into Windows with html file/folder groups and zip files. There are tons of third-party Windows Explorer extensions that change the way files are displayed. You can definitely create virtual nodes and hide nodes that you don't want to show (even in native open/save dialogs).
While I have no doubt that it would be possible on OS X, I suspect that easy-to-use hooks are not available for Finder like they are in Windows Explorer. You can write a QuickLook extension for Finder though.
(Some file browser extensions are easier to write than others. The image sequence in particular would definitely be easier to implement
thanks everyone for clearing this for me... I guess you learn something every day, even after 30 years of programming. I would have never thought of the infamous "computers are good at processing text" argument. Is there an archive of pro-vi arguments somewhere?
Now you can feel fulfillment when you log into your graphical OS and instantly open gazillion terminal windows to bypass all the progress that has been made in last 20+ years... because computers are better processing text then graphics.
I grant you one thing: when you sit in your cafe pretending to work on something infinitely more important then everyone else, girls/boys will be impressed by the complexity of your screen...
If you're editing files live on the server, you're doing it wrong.
This argument ("Oh I use <insert console based editor> because I can use it on my laptop or via SSH on the server") is fucking stupid.
If you can learn how to use fucking vim or emacs, you can learn how to use configuration management - either through a "full blown" tool like puppet/chef/ansible/etc or through config packages (if you're on debian) or even through plain old shell scripts.
Except when it's not really your call. And you have to poke around files so far down behind God's back through a shared desktop Enterprise VPN IE-only plugin-fest, that you don't even know which way is 127.0.0.1, then you're happy that you have vim on Dear Client's pointlessly supported RHEL boxes by default.
And othertimes, when you want to debug something that only happens on a live/production server.
Editing files on the server live is - in itself - not right or wrong. Doing it as a regular workflow is what's bad.
That's a long way from original claim that "the vi/vim editing model is just superior to any other out there", though. "You may need it in some crippled environments, so it's handy to know" is a considerably weaker claim...
You can host a non-production development environment on a remote server. That can help ensure it's as similar as possible to your production environment, as well as making it easier to move between locations / computers without having to sync your Dev environment.
Oh, and if you're editing system config files for systems administration tasks? That's on the server. As GP said, if you come from a sysadmin background, you're used to using a keyboard-only editor. And Vim sure beats ed.
Configuration files should be modified/replaced by configuration management systems/tools - that was my whole point. You don't edit code live on the server (you commit it to vcs and have a deployment system, right?) so why would you edit config files live?
Until a few years ago, almost nobody did things this way (the tools just weren't there); and even now, there are plenty of people who don't. It's too much overhead to deal with if you're spinning servers up and down only infrequently.
No one cared about anything until we discovered/identified a better way to do said thing.
If you're doing it infrequently this is even more of a reason to use a reproducible system, otherwise recreating the environment when the inevitable happens is even harder (you don't even have the benefit of repeated steps to aid you in the process)
I know some of the existing tools are a massive overhead for small operations - that doesn't make the goal in general any less worthy.
It is even more obnoxious when they are wrong. For one Emacs is a better editor, but that aside if you are using an editor when there is a good IDE you are doing it wrong(TM). Yep they are huge and bloated - but so was Vi back in the day - but your computer has both the space and the power to run them, while your brain hasn't.
You need type completion because your brain shouldn't worry about whether the method is called `updateBufferFromStorage` or `updateBufferStorage`, it should be focused on writing the best possible code.
Vim has basic word completion in insert mode with Ctrl-N/Ctrl-P. Extended completion is available with the Ctrl-X commands, including completion by syntax, line, filepath and a few others I don't frequently use.
I agree with the statement "use the right tool for the job", but people shouldn't diabolize something without knowing why others swear by it. FYI, in most cases we use Vi(m) because it's the fastest text editor available, not an IDE.
When I was new with SSH and everything, I managed to enter vim on my session on a server I was managing. Didn't manage to exit. So quit the SSH session and logged back in, still in vim, what to do? Well, I logged in as another user and rebooted the server. Not my proudest moment.
Back at my first job, since it was a fairly infrequent occurrence, I would occasionally ask my boss how to get out of vim. He would laugh and enter some new convoluted command every time!
For the article: If you try to argue for superiority, you should probably check the alternatives first and give an example where your preferred choice is obviously superior - the example of adding an empty body to each method is a great example where Sublime with multiple cursors beats vim (sure you can get them in vim to, but it doesn't show vim being superior).
For vim itself: I have seen friends trying to learn it. I have seen PhDs and postdocs use it. I have seen coworkers use it. The only people who I could see were editing text as fast as friends/PhDs/coworkers using Sublime were my tech leads. The smartest most proficient and effective programmers I have ever met. Everyone else was slower, at times wrestled with the editor (by this I mean that they executed commands and had to redo them because they didn't do what they wanted). I guess the conclusion is that people can learn to use vim as proficiently as Sublime, but most will fail or it will take them years (and I mean 5 or 10 years).
Actually, two of my tech leads, when I showed them some trick in Sublime were like: I should look into this. Maybe I'll just boldly argue that vim is inferior after all :).
I started with Textmate, liked it, but then the community lost interest. I followed them to Sublime. I never got comfortable with Sublime though it is hard to recollect why. I just kept getting frustrated with it.
Then people started talking about Sublime 3, Atom, and all that editor hotness. I wanted something stable, something I could learn once and be comfortable with it being around for a long time. I had tried Emacs years ago and found it unpleasant, to say the least.
I looked into Vim. It became very addictive but it does take a bit of time to learn. I love the action followed by motion idea. I found the built in tutorial decent as well as Painless Vim to be a decent starting point: https://leanpub.com/painless_vim
About a year into my Vim conversion, I get around decently and love doing the editing stuff. But I do feel that I need to go over tricks and tips again.
I've been a vi user for 25 or so years, and I really only know a few commands - how to search/replace, repeat last operation, search for the thing under the cursor, yank/paste, #[cmd], block mode, set mouse=a, and so on. In that capacity I have supported myself as a software developer, productively, with much satisfaction in my selection of editing tool.
So I'm often quite delighted at learning new things with it, even still! And to be frank, I think this is one of the things I most like about vim - even though I've been using it for years, there are still undiscovered treats yet to be revealed to me, over and over. When I discovered cscope integration, some 10 years ago, it was like getting an OS upgrade .. in my editor! :)
The vim commandline together with the power of regexs make it very convenient to convert text from one format to another. It works something like this(https://vimeo.com/15443936). I don't know how many hours I've saved on things like this due to vim.
funny how people pay attention to how fast it is to change a piece of text in a editor. Most of my time programming is spent on a piece of paper or a whiteboard designing my data structures and algorithms. Actual typing , especially with an ide providing auto completion, is the thing that takes me the least amount of time, by far.
Even if that is true, we remain human and annoyance is not typically subject to reason. When I'm typing in Visual Studio and I find myself spending a second moving the cursor from the top of the screen to the middle, it's a second that breaks my train of thought. Ugh, now I'm thinking about this editor. Instead of typing M and continuing with what I was doing.
I can imagine it to be a little like holding a speech with a stutter. Sure, most of your time is spent on prep. That doesn't make the pauses less annoying when you're actually talking.
I don't believe that to be true, and I have never met a developer who thought that to be true. Sketches and diagrams can design a large system, but at the end of the day, unless you're a systems architect or something, you're going to have to get your hands dirty.
The best and lowest-maintenance pieces of code our team has written were carefully designed and thought out before a line of code was written. I'd say 20% of the actual work was coding, 30%/30% for design and testing and 10%/10% for requirements analysis and deployment.
However, often we know that we don't know how to properly design something and we start implementing too early. The end result is sth like: 50% coding, 30% testing and the rest is squeezed into testing, deployment and requirements analysis.
Starting on a paper instead of coding directly is really the key to the best quality software i've done.
Funilly i realized that very early at university, where i had to perform a code exercice while on holidays, but forgot to take my computer with my me. I did it on paper, then typed it when coming back home, and got the best grade.
The measure of a tool should be: how much of an improvement is it over not using it. It's not about how fast a bike can go, it's how much faster it is than walking.
vi can be a huge speedup doing text manipulation. Programming is not just manipulating test, but manipulating code. An IDE helps me with syntax, completion, extracting/inlining, modifying signatures, refactoring, etc.
A corollary is: if you're making a tool, make sure it's leaps better than the simplest alternative. I have a friend who gauges lasagna at a restaurant against Stouffer's frozen lasagna. Because Stouffer's is delicious and if I'm going to a restaurant and paying a lot, it has to at least be better than something I can easily heat up at home!
I see it a bit differently : why spend time learning a weird way of updating text in a file when that activity isn't the most time consuming one by far ( and there are many more important other things to learn).
I never sketch anything out and designing data structures is done in the editor.
Why are you spending such a vast amount of time on something so simple as data structures?
Seriously. It's pretty much a solved problem these days. You should have read enough of other peoples code to see the common patterns, especially in your industry.
I'm serious that if you spend a lot more time on white boards and paper than programming in this day and age, there's something wrong.
Every original algorithm ( or even an original GUI component) has its pending original data structure. Designing an algorithm most often starts by identifying its parts and most adapted storage&query structure.
I suppose you're just writing boilerplate code, assembling pre coded components within the boundaries of a framework... That's the kind of boring job i usually try to let interns or beginners do, mostly because it's not economically interesting for customers to have that kind of job performed by senior devs/architect ( it does take more time than brain).
We're way past the decades where you had to sit around "thinking" for ages to come up with a data structure. You still loading the program up on cards or something? You saying it is as preposterous as the guy I met a couple of years back who offered to come and design SQL DBs for me. It's just not done any more. That's not how we work any more, that time has past.
In today's world you can prototype up the basics of any complex system in an hour or two and throw it away if it doesn't work. Tests are cheap, it's easy to mock, there's no compilation to worry about. And if you can't look at a problem and immediately see the effective ways you've solved similar problems before, well, you're not as senior dev/architect as you think you are.
It is indeed a very dated method, but you should try it once. You'll see that by thinking first, coding later, you'll gain a lot of time overall ( you're not always able to see with your code that something doesn't work).
Now of course you don't need this method for trivial things, but i hope that's not what you spend most of your time working on.
As a long-time vi/Vim user, I thought this article provides an excellent
explanation for non-vi/Vim users for the reasons why enthusiasts choose to use
such an old and unusual (for those coming from a GUI background) editor.
In particular, the author emphasises that you leave Insert mode as soon as
you've stopped typing. When I first started using Vim, I used to spend too
much time in Insert mode while moving around using the arrow keys.
What I learned from the article: If you're not positioned on a parenthesis, the `%`
command will “scan character by character to the right, until the first one is
found, and then moving to the character matching that one”. Until now, I’d
always been using one of the `f`, `;`, `T` family of commands to move to a
parenthesis or equivalent character. This will be a real time saver.
I started using vi in the 90s and got very used to it. It's still my standard text editor (the nvi implementation, that is).
I've never grasped vim. It was too slow at the time and the extended command set consumed all the free keys I use to have available to do my own macros (eg: 'q' 'g').
I reckon vim grew to be much more than an editor, it is now an editing plataform, capable of so many things, and contains lots of shortcuts / builtins for common text-editing situations.
The article above contains many vim-only commands. For example 'di>' ("delete inner angle-block") doesn't exist on standard vi, neither the '>aB' ("indent a Block").
vim is very slow; "classic" vi, and more reasonable clones like nvi are much faster and that seems completely wrong to me. It also has terrible defaults (like kindergarden-useless syntax highlighting which only make it slower!).
I have hopes that neovim will sort some of that out -- it makes a certain amount of sense that vim is slow because of some baggage it carries, but I'll admit they aren't very high hopes: I've been using emacs recently.
How funny is that? That I use emacs because vim is too slow!
Haha. When I first this, I thought your problems might be from editing large files with syntax highlighting switched on. Or doing PHP or JSP, which I've found to struggle in the past. But then I saw the username.
Indeed, if you're writing lots of code with hardly any newlines (like k lang), you will probably have performance issues with vim.
> It also has terrible defaults
This can vary from distribution-to-distribution. Certainly the default debian setup comes with annoyingly intrusive defaults, some of them used to have an impact on speed. Three settings you probably want in your $HOME/.vimrc on debian:
filetype indent off
filetype plugin off
filetype plugin indent off
[this might be obsolete - that config is more than a decade old]
I once worked at a company where I had to use Visual Studio. Now I can't believe I cared that much about it, but I basically refused to write code without vi. ViEmu saved the day, it was absolute magic.
"No, they are not dinosaurs who don't want to catch up with the times - the community of vi users just keeps growing: myself, I only got started 2 years ago"
Using batch to write FORTRAN, the editor was a card punch. On the Deck-writers (teletype) and VT100 terminals, I used to write Pascal, Ed was the only choice. Early Linux use forced your hand, Ed (again? NO) or Vi. This is because Emacs is a 30Mb download and where space was a premium. [0] Try using anything but Vi or Ed with Busybox. [1]
So I stick to Vi(m). I can use any cli editor but with much time and effort in Vi usage why change? I can but why?
Admittedly I haven't been using vim more than a few months, but I wonder why all the move commands are based on text structures, such as lines, spaces etc.
Wouldn't it be more useful to have commands for going to expressions, blocks, scopes and other code level structures?
I see vim people suggesting always leaving blank lines around functions, so you may use paragraph shortcuts to move them around. Why?
Some users also use Vim for editing plain English. I compose most of my emails in Vim and am currently (re-)acquainting myself with Mutt to avoid switching back and forth between GUI windows -- though maybe I just have a masochistic streak.
Because then it has to know what all those things are, and to know it has to parse and even compile the code. Basically a whole load of effort which isn't transferrable between languages.
Embedded developer here. A lot of times I need to edit a file on the target and I can easily put vi on the target system through busybox. Having the same editor on both sides is a nice thing.
For me, vim didn't have a steep learning curve. I've barely scratched the surface of its command set and basically know very little of it, but I didn't need it to be incredible, just better than TextMate.
And that's where neovim comes in. I makes me so excited. You can write plugins in any language. which is just plain awesome. I switched to the neovim alpha in archlinux last week. Wasn't the most painless process but it worked. pacaur hung installing it so I had to makepkg the package manually and get the dependencies manually. But hey it works. The dependencies seem to change quite often as well so sometimes you end up with dangling dependencies that you don't need anymore. But apart from that, once it's installed, You won't even notice you're not using vim. + The fact that it has a fully fledged terminal emulator built in is pretty slick.
I was exposed to vi 15 years ago but not until recently have I decided to get better at it. This article was great and helped a lot. It's a fun skill to improve.
I was fortunate to learn vi by rote, in a series of lectures where there was no computer in the room. Yep, copying the likes of ':wq' from the hand-written blackboard to A4 paper, along with all of the other 'handy' commands, some of which such as 'yank' I do not use to this day. This was a whole different way of learning with the notes referred to rather than things getting 'Googled'. Was this a better way to learn vi?
I don't meet so many 'vi' experts these days, if anything I feel embarrassed to be using 'vi' and associated command line tools like 'grep' when everyone else has some auto-completing high-speed IDE instead. I have to 'psr-fix' my code to make it sufficiently elegant. The problem for me is that I can do most things in 'vi' without having to hunt around for menus etc. Therefore, moving to the new is hard for me. In some ways I am like a secretary knowing 'Wordperfect' 25 years ago and unable to adapt to 'MS Word 2.0c' due to the same UI problem and convenience of known tools (Wordperfect, Vim).
I also do not feel that 'vi' works well in a team, people with Mac-gui-loveliness computers just can't edit things on your computer on an ad-hoc basis, some visual editor has to be found just for them.
If you are a vim person then these funny new-fangled 'gui' editors are really dangerous. It is far to easy for the document to end up with mystery 'j' characters added to the first line, ':wq!' added somewhere at the end, maybe with some randon 'ijk's' in the middle. If you are a vim person then every editor should have an 'insert' and 'normal' mode, not just 'insert'. The rest of the world doesn't see that though.
With people that do use 'vim' I have noticed that everyone does things differently. Some people will regularly use a feature that you never use, to make you wonder why you don't know that trick. Life without the correct, personalised '.vimrc' file is also quite hard, however, I have found some of these that others use to be overly 'souped up', for instance the search, I really do not like the search-as-you-type option, old-school is better, where you need to press enter.
So everyone finds their own dialect of 'vim'. Like car drivers, everyone thinks they are a good 'vim driver' apart from those that haven't learnt to drive. And they shouldn't. Amazing that vim is, it is a relic of former times, there are better tools with better 'UX paradigms'. In my field none of the 'programming gods' use 'vim' as they can't get to their productivity levels with it, so they use modern IDE's for their work, retaining enough 'vim' for any server side config file editing.
> If you are a vim person then these funny new-fangled 'gui' editors are really dangerous. It is far to easy for the document to end up with mystery 'j' characters added to the first line, ':wq!' added somewhere at the end, maybe with some randon 'ijk's' in the middle. If you are a vim person then every editor should have an 'insert' and 'normal' mode, not just 'insert'. The rest of the world doesn't see that though.
Turns that many of these (including IDEs like Visual Studio or Eclipse) have add-ons or built-in modes which emulate a useful subset of vim's behaviour.
> Life without the correct, personalised '.vimrc' file is also quite hard
Is it? For server-side work, I have a "light" vimrc of a few lines with sensible settings (status bar, nohidden, expandtab, this kind of thing). It is trivial to recreate if I don't have a copy. I have a longer vimrc and quite a few add-ons, but it's for more specialized work, not really anything I need for editing a remote configuration file.
> In my field none of the 'programming gods' use 'vim' as they can't get to their productivity levels with it, so they use modern IDE's for their work, retaining enough 'vim' for any server side config file editing.
In a large part, it depends on the language you use. Nobody sensible would work on a mid-size Java project in vim.
Throughout the learning process one thing I observed was that, its just not enough to read about a cool article about Vim and leave it there. I would keep repeating the sequence of actions mentioned in the article atleast ten times every day and would find some usage for it during programming. I would intentionally force myself to use it, until at some point, the action I just learnt magically comes in as a replacement for a dumb action I was about to do. At that point I would know I've mastered it.