Hacker News new | comments | show | ask | jobs | submit login
Best of Vim Tips (zzapper.co.uk)
290 points by henrik_w 734 days ago | past | web | 126 comments



Let me add one Vim tip that recently got me:

http://www.emacswiki.org/emacs/Evil

Seriously, to me it solved all my issues with Vim. Now I have several processes attached to my "Evil", heaps of plugins installed, yet everything blazing fast. And the configuring in elisp started as a little awkward, but now it feels so much more sensible then vim-script (especially knowing that development on Emacs started ding the 70s).

With Evil I can say that --for me-- the Vim/Emacs fight is over:

Emacs now has a great editor...

...and Vim a proper "operating system".

:)


I was a long time emacs user, and switched to Vim due to typing pain. Even with Evil, I can't see moving back. Vim + Tmux + YouCompleteMe > Emacs. There's just no comparison. No Emacs shell will ever be as good as zsh, and there's always some latency for some reason when using shells running in emacs. And, there's no youcompleteme.


Evil still lacks q: and q/ for command and search history editing. Really pains me that they haven't implemented this yet. There's also nothing that 100% replaces the CtrlP plugin for Vim on Emacs.


Please vote up the features you think Evil might be lacking, or better yet, contribute to the development effort :)

https://bitbucket.org/lyro/evil/issues?kind=enhancement&sort...


And people complain about UI discoverability in vim, but the fact is if you know how to quit out of vim you will sooner or later bump into the command history; if you experience rogue-like joy in the at this moment you know vim was meant for you.


I don't know if it's by default but Vim also saves search / command history across sessions. So if you quit or accidentally kill the terminal and open Vim again, that history will still be there.


Yeah setting up fuzzy finding on emacs is a huge pain. It's not a hard problem to solve, so maybe if I end up making more use of evil I'll try and write something although elisp is not fun. I currently use helm, ido and projectile and it only kind of works as good as cntrlP or command+T on textmate or sublime text.


I use Evil with emacs prelude now. Has more than enough features I need.


same here, also ido+helm+projectile; and not that ctrlP feeling yet.

i think this will be solved though (or is fixable), Vim on the other side does not seem very fixable to me.


I've been thinking about trying this out for a while now. I just haven't mustered the courage to make the jump. It would be great if there was a tutorial focused specifically on helping vim users who know basically nothing about emacs make the jump.

With that said, is it really worth it if I already use vim along with tmux? This is probably what has kept me from trying out emacs before. Vim isn't an IDE, but with appropriate use of tmux it feels like it can be one.


It's hard to say whether it is worth it. Is there anything you're missing from Vim + Tmux?

The best thing would be to just check it out if you're ever in a playful mood but the chance is pretty big that just playing around with Emacs for an hour will not be enough to convince you to switch.

Feel free to mail me about Emacs so I can help you as Vim user on the way and if you keep notes you can write that "Emacs for Vim users" guide that you asked for.


I can't wait for neovim. The promise of a better scripting language, better remote editing experience, better native GUI support on non-linux platforms, and better IDE integration has me itching to try it out.


Vim has seen active development for over 20 years and is available almost anywhere due to this. Reimplementations are announced every now and then but usually fizzle out after a few years. We'll see how long neovim stays around.

(And the MacVim native Mac UI is pretty nice imho.)


I'm really stoked about neovim. I hadn't really thought about it, but it'd be interesting to really go through all the substantial efforts to fork/clone/refactor vim and compare/contrast their primary goals and vision with neovim.

Might be fun to do some light reading on it tonight


I was really excited as well, until they decided to remove the encryption completely.

The nice thing about the encryption in vim was that it was a cross platform way for encrypting and decrypting plain text. I use it nearly everyday on my (work) windows pc, headless ubuntu server, macbook pro and nexus 5. And the only thing I have to do is open the file with vim.


That's a bummer for you, but does it really kill it completely? The way they are going it seems like they are making significant tradeoffs to remove legacy code in order to support modern features on modern systems. This should make it possible to be a true competitor in the GUI space to Sublime, but at the cost of ubiquity. I expect vim will continue to live on in most Linux distributions for the foreseeable future, even if neovim gets major traction amongst developers.

And personally I am fine using neovim on my dev box, and firing up vim on the server. Is that a non-starter for you? Do you really need automatic encryption on all your daily editing tasks on your dev machine? And if so, why are you not using full disk encryption?


Every few days I see something that reminds me I really need to learn how to start contributing to neovim (probably by writing tests in lua). I really can't wait until it is ready to use and I can try writing a plugin.


I just pester people on the issue tracker - https://github.com/neovim/neovim/issues/696

I haven't been told to STFU and I get to keep a close eye on progress so it's a benefit for me.

It's worth at least trying to build it on your platform to try and iron out the CMake weirdness.


Well I want to wait until I have a chunk of focused time to dedicate to the project rather than pestering them without cause.


Though I always like to learn more about Vim, there are way too many commands in this list to call it a "Best of", and it seems that many of them are not actually that useful.


Yeah, it seems like it promotes learning by rote vs learning how it actually works.

Grok vim!

http://stackoverflow.com/questions/1218390/what-is-your-most...


Don't let this list intimidate you, Vim allows you to learn at your own pace, I was mashing h,j,k, and l for years before I learned the beauty of grouping movements (e.g., 12j instead of j 12 times). I try to learn one new thing a week so I can commit it to muscle memory.


It seems like so much of power vim use is about jumping 3 characters ahead or 12 lines down.

Is this for real? Do you count the number of lines or characters before you move? Do you look at line numbers and do the arithmetic in your head? This can't be right, right?


> Do you count the number of lines or characters before you move?

I think most people use commands like f) (move to to the next ')' on the current line) more often than something like 12k (move twelve chars to the right), because, like you say, counting chars is slower than mashing 'k'.

People just use 12k because it's a simple example of how vim commands can be chained together. As a less-contrived example, you can do 2f) to move to the second ')' on the current line.


I believe there is an option to display relative line numbers to your cursor position. Really helps with jumping X number of lines.


Personally I just estimate and correct. Usually I use numbers that are easy to type with the left hand so I can keep my right on the home row. If the place I'm moving to is 17 lines up, I'll likely get there with 15jjj. Even with relative line numbers turned on, that feels faster for me than stopping to look at the number. (Haven't timed it, but feeling fast keeps me in flow so that's my metric.)

Various semantic movements help a lot, too. But I never stress on hitting the target exactly, I'd rather get nearby without thinking than stop and think to get there in one command.


It's more about "semantic editing" than memorizing arcane keybinds. With Vim, you describe what you want to do with actions and motions. Motions move the cursor from a starting point to an end point and then actions do something with everything between the start and the end.

For example, if you want to delete 3 words, there is an action to delete (d) and a motion to move forward one word (w): 3dw (read (3) times, (d)elete (w)ord)

If you want to delete everything up to a closing bracket, there's a motion to move to the next occurrence of a character (t): dt) (read (d)elete (t)o ')')

It becomes much more productive when you're thinking in terms of composing actions and motions to achieve a goal rather than memorizing situational key combos. The hardest part is getting over the hump of memorising the actions and motions.

Relative line numbers aren't even too important, given that there is a motion to jump to a line number. If you have a function that you can see starts at line 6 and ends at line 14 and I want to move it to the top of the file. You want to go to line 6 (6G), delete (d), go to line 14 (14G - thus applying the delete action to the motion of moving from line 6 to line 14) then go to line 1 (1G) and paste (P).


> For example, if you want to delete 3 words, there is an action to delete (d) and a motion to move forward one word (w): 3dw (read (3) times, (d)elete (w)ord)

I prefer to use d3w since it feels more like English. It's also more compatible with other combinations like ci" ('change inside quotes', e.g. to change a string), ca" ('change around quotes', e.g. to replace a string with a constant), or yt{ ('yank to brace').


% will bounce back/forth over matched pairs of (), [], {}. :/foo/z6 will move 6 lines after the line that matches "foo" (I know it's not eliminating counting). There are also word, sentence, and paragraph movement available.

I "bookmark" important lines with named markers "ma", "mb", etc for "a" and "b" markers respectively, available as 'a, 'b.

Not to mention cscope or ctags for finding function declarations, various call chains, etc., etc.

There are quite a few ways to get around.


I use relative line numbers so I don't have to count, vim tells me how many lines are between my current cursor position and wherever I need to jump to.


Hah, I didn't think of that! Just before reading this comment I was working along in the editor, furiously pressing j/k. I'll put this to use immediately.


In your vimrc add the following (version 7.3+):

    set number
    set relativenumber
This turns your line numbers into a hybrid mode that show the numbers relative to your cursor and the actual line number your cursor is currently on.


Yikes! The continually changing numbers drives me crazy. Thanks for the tip, but I think I'll stick with just using ":13" to go to line #13... I guess there is some benefit if you do a lot of yanking/cutting based on lines, rather than some magic matching or such. But for now, relative line numbers is not for me.

For (a little) more, see:

http://vim.wikia.com/wiki/Jump_to_a_line_number


This doesn't work for me in 7.3.429-2ubuntu2.1. It still shows 0 for the line you're currently on.


That is way cooler than my old 'focus' hack. Thank you!


Generally in vim, if you're pressing a key over and over, that's a smell that there's room for improvement there.

In addition to counting motions, other great options for getting around include:

    % jump to the matching brace/bracket/paren
    ( jump back a "sentence"
    ) jump forward a "sentence"
    { jump back a "paragraph"
    } jump forward a "paragraph"
Also, getting around by searching can be hugely worthwhile.


Also:

    n jump to the next occurrence of the last search
    N  "   "   "  previous   "   "   "   "   "   "
    * jump to the next occurrence of the word under cursor
    #  "   "   "  previous   "   "   "   "   "   "


Yes! Also, ^R^W (ctrl-r, ctrl-w) when you're at the : prompt will drop in the current word under the cursor. Which is also quite useful in keybindings.


Thanks. That's a great tip. I've always yanked the word that I wanted and then used Ctrl-R" to paste it on Vim's command line. This is much better.

I'm now off to read "cmdline.txt" (:help Command-line).

BTW, I just accidentally closed my browser tab (latest version of Firefox) by hitting Ctrl-W when I wanted to delete the previous word in this textbox. That used to drive me mad but when Firefox restored the tab, it also restored the text I'd typed. :)


might want to switch to relative line numbers. makes using 12j/k much easier in my experience.


or alternatively try the easymotion plugin[1] which you press <leader><leader>j (or whatever you map it to) and then it will highlight each potential line with a letter that you press to go to that line. j is one of the worst examples, it's nice if you are doing a dw so you don't have to count the words, you would just do d<leader><leader><motion> and it will highlight to the potential places.

[1] https://github.com/Lokaltog/vim-easymotion


I love pages like this because this is how the internet used to be. weirder.


What do you mean by weird? The extremely high content-to-style ratio compared to a lot of pages today?


I don't know, if this were a "Top 10 vim tips, number 6 blew my mind" style article I feel I'd engage with it more. Also, show only one tip at a time with pagination so I can learn one thing at a time.


I don't know what the other guy means by weird, but I mean the extremely high your-brain-has-to-operate-like-a-combined-parser-and-compiler to make any sense of that kind of thing. You're telling me you're not dulled into a stupor by trying to read that?


s/used/should/

It's nice to not "read more after the jump" or "below the fold", no over-pagination, no 100% width 400px deep semi-relevant banner image, no pull quotes in 30px ultra-bold fonts floated over to the sides, no "you may also be interested in" and no asinine comments, .. oh, wait!


s/used/used to/


I disagree. This is way to much information for me to digest. I think a happy medium is nice. Enough information on the screen to get the point across but not too little that I have to click everything to find out what I need.


Of course I'm exaggerating, and I agree this page isn't particularly friendly but nor is it intended to be, its a reference to be searched rather than a piece of prose to be read.

A lot of pages I find frustrating are often trying to spin a narrative around what amounts to reference material, or vice-versa & results are often framed with the tropes I mentioned above.


It seems like those could even be two different views into the same material, potentially.


As opposed to the modern trend where there is too much non-information to digest.


Wouldn't you like to know how to do all of this in five easy steps? /s


...That Emacs Users Don't Want You To Know!


If you click on "Tips Home" it gets even weirder. Like the url for "Technical tips" being "make-money-online-tips/", and check the Blogroll.


:'a,'bg/fred/s/dick/joe/igc : VERY USEFUL

Wow, thanks for the tip, any ideas on what it does?

A lot of these seem to be learn to use regular expressions and not really vim related other than vim supports regular expressions. I.E. the 4 or 5 different ways to find an exactly 4 digit number that mostly seem to boil down to '/' does search by regular expressions and here is a regular expression that finds 4 digit numbers.


> 'a,'b

Between mark `a' and `b'

> g/fred

If the line contains the pattern Fred, execute the following command (s/dick/joe/igc)

> s/dick/joe/

Replace dick with joe

> /igc

i: Case insensitive

g: Replace multiple occurrences on the same line

c: Ask for confirmation on each substitution

I may be wrong about some detail, but I believe that's it.


If you use Vim with C#, you should check out the Omnisharp plugin:

https://github.com/nosami/Omnisharp

It provides intellisense, find-usages, and other features.


Also YouCompleteMe[0], which uses Omnisharp for C# and Jedi for Python. It has recently been refactored into a standalone server that talks to the editor plugin, so we may see this in other editors.

[0]: https://github.com/Valloric/YouCompleteMe


No official Windows support :-(


I've been using vim for the last 2 years, and I love HN for posts like these, with all a-ha's in one page. Considerably reduces time necessary to become a vi master.


These sort of tips are only useful in highly specific cases. It's probably not worth learning them off by heart because of how infrequently you'll end up using them. BUT, understanding how the author(s) came up with these is incredibly powerful. The combinatorial explosion of the composition of Vim features means that it's practically impossible to learn all of the commands.

That said, it's really beneficial to learn how to form these commands yourself. For instance, if you know regexes, a good chunk of the commands presented would be relatively easy to come up with yourself. Is it worth learning regexes, Vim shortcuts (basically a lot of arcane things)? Maybe, maybe not. If you spend (or plan on spending) a huge amount of time manipulating text files it's probably worthwhile. For me at least, it's much more satisfying to do most text manipulations (e.g. remove trailing whitespace) by running a concise command, than doing it manually.

For what it's worth, it's even fun to sit and think of how you can avoid doing some manual task. Vim shortcuts + regexes are a really good way of avoiding silly work.


Some useful tricks in there.

Also, this:

  ggVGg?                          : rot13 whole file (toggles)
So g?<motion> applies ROT13 to text. But... why?

Edit: Make that "a couple of useful tricks in there". These are the ones I can actually see myself using:

  @@     last recording
  @:     last command-mode command


At a guess: the old-fashioned Unix way of composing mail and Usenet messages is to have your client call your editor. Rot13 was (is?) common in Usenet discussions of fiction to avoid posting spoilers where anyone can accidentally read them. It's not something you would use when editing source code.


You know when you read someone's comment and then your immediate thought is "I'm way too old to appreciate this"? I read your comment and thought the exact reverse. I'm way too young to appreciate this.

Thanks for the insight!


"old-fashioned Unix way of composing mail and Usenet messages is to have your client call your editor"

Some of us still do that. I <3 nmh.


What's nmh?

I must admit to setting $EDITOR to nano for mutt.


nmh is a mail client that is decomposed into a bunch of shell utilities, storing state and messages in files. It's a bit awkward trying to use it directly, but easy to wrap things you do commonly in aliases/functions. Editing of messages, of course, takes place in your $EDITOR, but listing of messages, selecting of messages, &c, doesn't leave your shell like it does with mutt (so you can use the pieces as part of arbitrary pipelines, as is good and proper).


I wish Reddit would implement that.


Does Reddit not have [spoiler] tags?


Yes, but they're CSS dependent and can often be broken on mobile clients


Just a nitpick, but applying a command to the whole file can be done faster with ggg?G That also has the benefit of working with plain vi, since vi doesn't support visual mode. I didn't know about the rot13 command. I probably won't ever use it, but I think it's fun that it exists.


Are you asking the mechanism? It's because ? is defined as an action to rot13 the selected text.

Are you asking the motivation? I presume it's because someone wanted to be able to easily obscure things like spoilers in messages to mailing lists.

As a mnemonic, it doesn't seem unreasonable.


For me, just using NERDTree and ctrl-p combined with basic skills from the tutorial made me love vim :)


I love Vim but never use it. 99% of the time I'm editing code in an IDE that knows about the language semanticly and knows how to refactor (extract/move/rename) code. It would be incredible if Vim/Neovim had a plugin that could do the same refactorings as IntelliJ.

At the moment the ease and frictionlessness of refactoring like this (instead of manually moving text objects around) beats Vim's productivity gains. It's a shame because I still often think in terms like "ci(" when using an IDE.

I've tried Vim emulators in IDEs (not recently, mind) but they're not the same.

Anyone have any suggestions to get the best of both worlds?


I'm a relatively happy user of Vim emulators in IDEs (mostly in VS / IntelliJ / Eclipse); e.g. I might do a cw / ciw / ct[first letter of next word in variable name] and then hit the IDE's shortcut for rename refactoring. Simple macros for tedious repetitive tasks. For this, I find emulators sufficient, a kind of "best of both worlds".

I suspect my usage of Vim itself is fairly basic, making this workable. What issues did you find with this approach?


I really like vim and use it every day, but I'm honestly never going to commit all this to memory.


I think you are very much wrong!

I started using vim only recently, and when I was running through vimtutor, I was telling myself how I'd never be able to remember or understand what is w, W, B, E, {, dib, ci(, ma{{{yy`a"bddp (maybe there's a better one than this) or :%s/a/b/g.

After only a month or so of usage, I've come to use commands and sequences like this by heart. And when I read useful tips or watch screencasts, I'm just remembered how I've barely even scratched the surface of productivity with vim.

That's why I don't fear I won't be able to remember more and more new, complex commands. I think it will all come naturally, like the first ones I learned. The same should happen not only with me, but with you or anyone else who is dreadful of remembering increasingly complex workflows of commands with vim.


One very useful advice when it comes to 'what to memorize' is trying to always watch yourself using vim. If you happen to do something repetitive, ask yourself: is there a better way to do it? How to automate it? And then, commit this new tip to memory. This way, you actually only memorize what is directly useful. This tip has served me very well.


in unix, you memorize by doing, not by studying


I would actually venture to say that it does not apply only to Unix but for life itself, no?


Sort of let's me wonder, why anybody would want to learn all those. I use vim regularly, but to be honest, for 90% of tasks i would be just as efficient with pico or mcedit.

I guess i am using vim only because it is most often available on 3rd party systems and because of the occasional need for those last 10%.

And to be honest, i used to use vim on the desktop for some time, but now we have this variety of options.. from fast loading textadept, gedit, sublime text3 to full-blown IntelliJ.. Why vim? Because it's "cool"? Feels more like ancient and antiquated.

Nice list though, it's bookmarked for those 10%! :)


Hardly anybody would want to learn all of the features ofcourse. There are advantages of using vim which other editors can't compete with (imho):

- A just booted VM with with no window manager installed. You have very few choices, but can always count on vi being there.

- Abstraction: One builds up the knowledge of different things over a period of time. For exaxmple, once you learn 'w' is next word, it can be combined with the new knowledge of 'd' for delete quite intuitively. Not saying other editors don't have that.

- Each popular editor I know of has a VI mode built in (or easily available). So, being comfortable with vi means being able to use any of the mainstream editors with vi mode, but not the other way around.


It's useful to see how others apply vim's grammar in interesting ways. To me, it's like seeing a new design pattern. Not necessarily immediately useful, but a maybe a new way to think about something I may not already know.


That's the way I approach some lists like this one. Specific examples can help one to in turn better learn and generalize certain abilities/behaviours.

I'll also add: So, one person puts up a long-ish page of examples. Is there anything inherently wrong with this? Presumably, it's useful to them and perhaps to some others. Doesn't that suffice -- it's the Internet!

Not every page needs to be carefully curated for global karma-whoring.


I didn't question the usefulness, i still often use vim and i am regularly amazed by it. But still.


I hope I never have to use (most of) those.


As a VIM user I am overwhelmed by this tips webpage which, despite in small font, requires 16 page downs to reach the end. "Just use Sublime Text"[0]

[0]: http://delvarworld.github.io/blog/2013/03/16/just-use-sublim...


Another Emacs user here. The article is bullshit. If you use Sublime Text now, in a few years you will be using another editor (Atom?) and so on, or you'll become a dinosaur stuck with an outdated OS just because you need your favorite editor (similar to how some people still cling to WordPerfect running on DOS). On the other hand, Emacs and Vim are eternal: once you learn them, you're set for life, and you'll only get better at using them as the time goes on.


"Just use Textmate" or "Just use <Propietary Editor>" doesn't hold much water.

Vim is a hot mess in some regards, especially the scripting and plugin system. However, it's available virtually everywhere. I'm holding out hope that modern versions like neovim will address some of the legacy issues.

https://github.com/neovim/neovim


To be fair, the OP says it is 23 years' worth of tips. I think the intended audience is probably people already using vim for 5+ years, who are ready for this stuff?

(As for "just use Sublime", I'd say just use Emacs :P -- but seriously both are probably OT for this.)


I program in both Windows and Linux environments, Visual Studio for the former and Vim for the latter. When I transition from Windows to Linux (and thus VS to Vim), I realize how much more I enjoy Vim. Even with VS's fancy intellisense and other similar features, I'm still faster in Vim. And every time I learn a new trick, I like Vim even more. And I've only been using Vim for a few years. I wonder how much faster and better I'll be after five more years of using it.


You should give a try to VsVim [1], a plugin for Visual Studio that provides Vim emulation. It supports a lot of features [2] and settings [3] and, most importantly, it is Open Source (it is also written in F#, which is nice).

It's always the first plugin I install in Visual Studio, I cannot work without it. It might not suit the needs of more advanced Vim users, though.

[1]. http://visualstudiogallery.msdn.microsoft.com/59ca71b3-a4a3-...

[2]. https://github.com/jaredpar/VsVim/wiki/Supported-Features

[3]. https://github.com/jaredpar/VsVim/wiki/Settings-Reference


I used VIM as my only editor for something like four years, but I've got a full time .net/C# job now.

I can still use vim shortcuts comfortably and such, but setting up the environment was always a pain for me.

I was setting up an editing environment on a linux VM at home to write some Haskell, and started looking through vim plugins, etc. I got sick of it after five minutes because I didn't really want it to be a big thing, so I installed ST2 and the various haskell plugins. It took about ten minutes to get it running in a state where I could compile/build/repl from the text editor and have basic vim motions (which is really all I need from it right now). It also has a few things I really dig like the fuzzy command palette and multiple cursors (which are now available in a lot of editors, but ST2 still has the cleanest implementation that I've used so far).

I think the package manager/extensible side of vim is what really bugs me. Sure I can get in and figure it out, but I just don't want to most of the time.

Obviously this is a really superficial look at what vim has to offer and a very narrow use-case/problem; ymmv dramatically. I contributed a pretty solid chunk of change to the neovim project and I'm really a big fan of vim in general, but for that specific use case, I wasn't terribly happy.


> setting up the environment was always a pain for me.

I have never understood this argument. Copying my local .vimrc and .vim from one machine to another has always been enough to create an _exact duplicate_ of my environment. What's missing?


It's mostly to do with the various plugins that I use. I can pretty quickly get to syntax highlighting and editing with vim (read: instantly), but the other tools that I like integrating into my editing are where I hit a wall every time. Even with that I could sync everything via git or dropbox or whatever else that I wanted to do. It's just the fact that I have to dig through my mental notes to get it working. I also don't specifically have a VIM haskell environment to clone. (I don't have a sublime haskell environment to clone, either)

I'm not that it's necessarily excessively complicated; it's just not particularly straight forward, either. This could just be a failing on my part, but I haven't set up a vim environment in about a year, and there were enough confusing parts to do a little head scratching to get haskell plugins working to make me grab something else for now. With ST2, it's been about the same amount of time since I've set it up and only took around ten minutes to finish (that's with plugins to integrate HLint, compilation, a repl, type checking, etc).

Again, keep in mind that I said this was a very narrow use-case/situation. I'm not arguing that VIM is more difficult to set up for any case outside of the exact one I said. I'm not saying it is or isn't a generalizable point. I'd really have to do more digging to find out. What I am saying is that in this situation ST2 was easier to setup.

I'm also not arguing against VIM because of setup time/difficulties. Setting up a coding environment should be a relatively small chunk of the total time you spend using it to code. I'm just noting a relevant experience I had last night.


vundle: https://github.com/gmarik/Vundle.vim

you keep a list of plugins in your .vimrc, beats dropboxing hands down.


What tools are you trying to use that make it such a hassle?


Keep in mind that I said it's not excessively complicated or an extreme hassle. It was just less straight forward for me than using ST2 to get an immediate dev environment going with the haskell tools/integration I wanted (hlint, repl, error/type checking/hints, etc).


Yeah, it sounds like vim just isn't your thing.


Super late reply, but I don't think that's true.

I haven't written anything here that says I won't use vim, or that I don't plan on using vim. I used it for years before, and even given those issues, I'm sure I'll end up using it again. I love the feel of the modal editing and how far people go with plugins/extensions.

That said, everything I noted can be fixed and made to go away. It's all accidental complexity. Package management, plugin management, and installation are all problems that don't necessarily have much essential complexity. If the Neovim project keeps traction, it looks like it'll go a long way toward making all of those substantially easier, or at least toward making it substantially easier to create solutions to those problems.

Either way I'll continue to use vim, but I'll also probably use ST2 a bit as well. The next time I set up an environment, I'll just be much more careful to set it up in a way that makes it much easier to migrate to another computer.


Fair enough! To each their own.


There are certain features where this would be problematic. Things such as copy/paste to/from the OS clipboard, and a few extensions that require ruby support (since ruby isn't always available).


Yeah, that's the sort of thing I'm thinking of.

They're things that aren't horrifyingly difficult to setup or remember, but they make it a little more complicated and don't feel straight forward.

They're not things that would keep me from using vim, but for this particular context, they're things that made me decide to just throw ST2 on the vm


Agreed. I'm honestly not sure how it could be made easier.


I completely agree that this is a garbage "tips" webpage... it's not tips, it's a bloody reference manual.

HOWEVER: The article you linked is similarly bad. There are excellent reasons to use vim outside of "keep your fingers on the home row". Very common operations such as "delete the next 30 lines", "Move these 10 lines to just after line 150" and so on are much faster in vim and this is why I use it. I don't use it for hjkl (which is only there because of the presence of arrow keys on those specific keys in the 80s) and I certainly don't use it so I can write plugins in the god-awful vimscript. Although it's nice these things are there, that is really not why I use vim.

No, I use vim because it has a comfortable set of basic keybindings, which you will use a lot while you get used to the more complex ones.

Besides, it's not so much about using vim, but about using a good GUI editor with vim mapping.


Vim, keybindings and composability: https://medium.com/@mkozlows/why-atom-cant-replace-vim-43385...


On paper this works perfectly, in reality it doesn't.

A lot like Regexes. The first n attempts at a regex always fail, and fail for human reasons - I didn't spot that the pattern I'm matching on actually appears earlier in the writing, the pattern has a typo but I spelled it correctly, the pattern used a unicode character that looked like an apostrophe, etc.

And Vim composability suffers in exactly the same way. "Delete back eight words" works on paper, but eight words isn't a thing you can glance at, it means stopping and counting - especially not if it goes back over a linewrap. And does what about the word boundaries? If the cursor is in the word, at the end, at the start but still has to cross the word boundary to get to the previous word?

Combined with that, the way Vim commands have instant and unbounded effects means that the wrong command or a misspress of a key, and suddenly there's a huge change to the text and you don't know what happened. This leads to the effect where even if a change looks right, if it was a big change ("add a comma to every line just before the last word") needs a lot of careful verification to make sure it worked as intended.

In real world use, almost everything I try to do in Vim outside the everyday patterns of habit, takes enormously longer, works less well, is more fiddly and stressful, than 'just' doing it by hand or in Python.


You can get sort of a preview by going into visual mode with 'v' and then typing in the motion command, and once you are happy with what was selected you delete the visually selected text. I agree that its not very consistent here, because for a regex replace you would use a /c instead to get confirmation.

Regarding the 'I pressed the wrong key' problem there is undo (and if you enable undofile you can undo even after saving or reopening the file), and there is git history.

Having said that I agree that there are often situations where automating something (or using a more complex Vim command) would take more time than doing it by hand.


If it's important, I'm nearly always using version control which helps with direct or indirect fixing of misapplied actions.


In addition to composability, which I agree is a big idea, I believe there's another big idea in Vim: modal editing.


Yes, I know the article and wholeheartedly agree with it.


Can't use sublime text on servers and find Vim fits my use case better :)


I don't get it why someone would use a closed source tool to create open-source programs. Or why you'd use a closed-source tool for something as fundamental as editing a file.


While I enjoy using open source software on principle, in practice I care way more about usability and feature set. I understand that some people make a conscious choice to only use free and/or opensource software, but it's flawed to claim closed-source software is somehow unfit to operate, especially based on the "fundamental"ness of the desired action.


I agree.

As far as a business case goes, there's no real "vendor lock in" with a plaintext editor like this. You can always switch to something else and your files will be fine/the same. You're investing (potentially non trivial) time to learn using it, but it didn't take me long to learn ST2 to a depth that made it really handy.

I will say I'd buy a lot more into that argument for people who develop plugins.

That said I can respect the "open source" only mindset. I'm just not sure I'm that concerned about it in this particular case.


I don't know whats the lifetime of these "trendy" closed-source tools since I was never a fan of them, I'd be worried that you loose more time by having to switch to a new tool each month. Exploring alternatives is nice, but you can't be doing that all the time.

For example there was a time when I switched a Linux distribution each month, then at some point I realized that it is getting me nowhere: I didn't know either of them in-depth or how to deal with their specific problems. So then I made a choice: I'll use only Debian, and actually learn about how to deal with problems when I encounter them, instead of jumping ship to another distro.

Its the same with text editors, I eventually settled on Vim (for a long time without any plugins), then started using plugins as well.

Sure every now and then I check what new alternatives are out there (for example there are some interesting ideas in http://leoeditor.com/ but not really comparable to Vim), but closed-source tools are never on my list. I only ever heard about Sublime Text here on HN, and even then for a long time I thought its a Mac only tool.

But with closed-source tools I just wouldn't have been motivated to stick with any of them: if there were problems with it then I wouldn't know how to work them around, or implement missing functionality, not to mention I wouldn't trust them to begin with etc.


ST has been out for six years. That's not going to be comparable to emacs (mid 1970's - now) or vi/vim (1976/1991 respectively). I haven't jumped on Atom, or any of the other brand new editors because I want to know they'll have some staying power, but I don't think 5+ years is short enough for me to be concerned. I'm certainly not changing editors every month. I also do most of my editor exploration in my free time, and it's fun for me, so it's not really a waste of time (again, for me, in that context).

I should say that I can't really settle on VIM right now because I'm doing full time .net work at this point. I still use it reasonably often when I'm mucking about in C at home, and I used it as my primary editor for at least five years prior to that, but my use-case was me trying to get a decent haskell environment up and running on a fresh linux VM as quickly as I could. ST2 worked really well for that.


I also care about being able to use the tool several years from now or on different distributions/OSes, etc. With closed source you are locked to whatever the vendor provides, you can't just recompile it if it doesn't work on your OS anymore. Also I don't have the time to reverse engineer and check the software for backdoors (not that I do that with the open-source one either, but at least its more obvious if something goes wrong there).

If you work on closed-source software then you probably don't care about this / doesn't matter there, but as someone who spends most of his time working on open-source software I definitely want my editor to be open-source.


If the vim developers announced next week they'd only support Linux, I'd keep using the Mac version until it becomes worse than a newer tool and then switch to that. The same is true of Sublime or any other text editor.

I'm not going to be forking an open source text editor if development stagnates.


Except that with an open-source tool you have the choice of using it as long as you want. Once it is part of a distribution like Debian or Fedora it is unlikely that it gets removed just because upstream stagnates, and it'll keep running. If there are enough users the distros might even maintain patches of their own, or fork it themselves. See for eg. tinydns, where the original is so old it doesn't even compile, yet there is a working version in Debian.

With closed source you don't have much choice except running an outdated chroot with an old distribution, or stop using it.


That's the same logic that got us OS X Mac using developers for Linux :(


Because it doesn't matter. The closed source tool isn't going to hide stuff in your text file. And should they change completely in a way you don't like or stop updating you switch tools you aren't locked in since its a text editor.

And honestly even with open source if the main devs stop updating or doing something you don't like you're time is almost certainly better spent doing what you're doing on a different editor or the old version then taking over development on yet another text editor.


I think you could also ask the question in a different way. What is the market for closed-source text editors? We have open-source text editors, and freeware(?) closed-source ones. So who would buy a closed-source text editor? (Talking about a text editor here, not an IDE)

So then why not just open-source it? Seems to me there are only drawbacks in keeping it closed.


I've paid for textmate and sublime text because they were better than their immediate competition for what I use them for. I know lots of other people who have paid for one or the other. I have a really nice tmux + vim workspace I use a lot but for unfamiliar codebases I find exploring a lot nicer in sublime.


That article reads like it was written by a fifth grader describing reasons why dodgeball is better than soccer.


I am an Emacs guy, but even I know that vim do support ctags?!

That blog post reads like a rant, do the author really know anything?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: