18 ms·

Ten Years of Vim

153 points by omn1 8y ago

spicyusername 8y ago
All of the points in the "Some things I wish I could do better" section are the reason I use a regular memorization free-ish IDE. Out of the box the things I want to do are easy (multiple files, manipulating structure of blocks of text, searching and manipulating information across my project simultaneously) and the things that aren't are rare (Add a dollar sign at the beginning of the next 13 lines). I know how to use vim solely because it's necessary to edit files in a terminal.
- gwn7 8y ago
  > Out of the box the things I want to do are easy Easy what? Easy to learn or easy to do? They are arguably easier to do in vim once you learn the proper method. Just not as easy to learn. That a common trade-off shared by rather elaborate tools.
  - hungerstrike 8y ago
    Yeah "once you learn the proper method" is the key phrase here. The proper method being "use rote memorization to learn about things which could have easily been made available via some discoverable visual mechanism". GUIs make things easy to learn and easy to do. Especially on an OS like Windows where you can drive the entire UI with just the keyboard and about a handful of well-known keyboard shortcuts. So what's your point? Perhaps you're using a Mac or some other barely usable desktop system that has crappy keyboard acceleration for the UI?
    - gwn7 8y ago
      > The proper method being "use rote memorization to learn about things which could have easily been made available via some discoverable visual mechanism" I already said that this is a trade-off. Nobody's claiming that the vim way is the "right way" to do text editing. If you prefer a discoverable visual mechanism, you can go with it. But some people clearly prefer to "use rote memorization" because they obviously gain something out of it. And believe it or not, "rote memorization" is an essential part of our everyday life. Without it, you can do nothing. I don't see any harm in somebody deciding to apply it to text editing as well. Obviously thousands of people decided to do that, looking at vim's popularity. And lastly, the memory we are talking about here is the muscle memory. You put something there once and it's done. Using vim is very much like riding a bicyle in that sense. Would you prefer to have a bike that has labels on the pedals, brakes, gears; and prefer to go through those labels each the you need to use one of them? Memorization allows you to do things without thinking. The mantra of vim and similar tools is to enable you to become one with the tool just like you become one with your bike, your tennis racket, your sword (!), whatever. Touch typing really helps here as well. You can't understand that without investing enough time to that. (You don't have to. But you don't have to criticize it without really knowing what you are talking about either.) I use Arch Linux. Keyboard accelaration is perfect.
      - hungerstrike 8y ago
        Define rote: mechanical or habitual repetition of something to be learned. This is not something that is part of every day life at all. After school the only time I had to repeat something over and over with any kind of frequency at all was when I was learning vim. > Would you prefer to have a bike that has labels on the pedals, brakes, gears; and prefer to go through those labels each the you need to use one of them? That's not a really good analogy because my memory also works for GUI apps. However, I didn't have to use a rote method to get there. I just use the GUI with its labels and visuals helping me along the way. If I don't use something for a while, the labels and other visual elements are there to help me out. > Memorization allows you to do things without thinking. Yes and your memory works with GUIs too. But again, I didn't have to put myself through weeks of exercises to use a GUI. > You put something there once and it's done. I don't think so. Time is a thing and particularly with regards to lesser used features - you'll find yourself looking up things that you once knew. > I use Arch Linux. Keyboard accelaration is perfect. Sure it does... at least until the next update amirite?
        deleted 8y ago
        [deleted]
        gwn7 8y ago
        > Define rote: mechanical or habitual repetition of something to be learned. This is not something that is part of every day life at all. I can understand that. It was already clear that you are not the type to give time to learn about rather elaborate tools that have higher learning curves than the average. That's ok. It may not be a part of YOUR everyday life. But not everybody is living your life. The difference between you and me is that you are implying that vim is pointless and wrong. I'm saying that everybody should go with whatever works best for them and that every approach has their benefits. Also, attacking my operating system has nothing to do with this discussion. Not a very effective rhetorical method.
        hungerstrike 8y ago
        I agree that everybody should use what works best for them. So there’s definitely value in that. Typically when I pose an argument in a thread like this, about a technology that I don’t prefer, it’s due to the fact that a multitude of users have badgered me over my own preferences elsewhere, saying that their technology is clearly superior. I use Windows, Linux and Mac in that order of frequency and I like them all for different reasons and I dislike them all for different reasons. A ton of users on HN react badly to anyone who isn’t just like them. So, I was being a bit defensive sorry.
cgag 8y ago
It's highly overstated how hard it is to learn imo. I would learn it again without a doubt.
- mattbreeden 8y ago
  I ran 'vimtutor' twice and felt comfortable enough to switch. I think the only reason people think it's so difficult is they maybe try to go too deep too fast?
  - remar 8y ago
    Most of the people I've talked to who gave up on trying to learn vim didn't even know vimtutor existed.
  - didymospl 8y ago
    I repeated vimtutor for a few days in a row trying to following this nice Vim learning plan [1] I saw on HN and I gave up trying to switch to Vim as my main text editor after that. Even though I knew how to perform most of the basic operations, the fact I had to switch to normal mode to do anything more complex than editing of the current line felt just too unusual to me. I mean, I'm comfortable editing files on remote servers in Vim now but I don't think I'd ever be considerably more productive in Vim than in IntelliJ/Sublime. [1] https://medium.com/actualize-network/how-to-learn-vim-a-four-week-plan-cd8b376a9b85 https://medium.com/actualize-network/how-to-learn-vim-a-four...
archi42 8y ago
Regarding tabs: I bound F2 to previous tab, F3 to next tab and F4 to new tab. Besides highlighting the current line, I think this is my most important customisation.
- omn1 8y ago
  Oh that's cool! Think I might do that, too. Thanks.
- pault 8y ago
  Isn't `gt` and `gT` faster? You don't have to move your hands!
  - roylez 8y ago
    It isn't. I use F11/F12 for previous/next tab, in tmux and browser, and I can confirm it.
  - JoshMnem 8y ago
    I like `gt` and `gT`, because they are available out of the box on remote servers too.
    - Lio 8y ago
      Also you can use <num>gt to jumpe to, say, second tab.
  - geowwy 8y ago
    `gt` will still be slow because you're using the same finger for both keys.
- ropeadopepope 8y ago
  I went a slightly different direction. CTRL+N is next buffer (ie: tab), CTRL+P prev buffer, LEADER+W for close buffer. I don't make new buffers a lot, so I just type out :new when I need to. Opening an existing file is LEADER+F, which opens fzy via vim-picker. I reserve the F keys for toggles. F2 is set to pastetoggle. F3 turns numbers on and off. F4 turns special characters on and off.
nurettin 8y ago
Only 10 years? Feels old, man.
keithnz 8y ago
The point in the article is that the Vim keyboard bindings are most useful. Most editors have an option or plugin for that. That's what I use mainly. For instance I use Visual Studio + Resharper + VsVim ( + AceJump + RelativeLineNumbers) as my main development enviroment. I also use webstorm configured in a similar fashion. Visual Studio and R# understands the code and how to manipulate code far better than anything in the Vim world does, but I use it in combo with Vim keyboard bindings and it becomes incredibly quick to do things. I don't actually use Vim itself very much ( I still use it for various things, but its not my main editor ). Its nicest attribute is for quick editing tasks it loads quick and can load very large files.
darthlucio 8y ago
I know you said that you like maintaining a super minimal .vimrc, but fwiw there's a couple of plugins that really helped me with the workflow issues you mentioned struggling with: > Jumping around in longer texts: I know the basics, like searching (/), jumping to a matching bracket (%) or jumping to specific lines (for line 10, type 10G), but I still could use symbols more often for navigation. vim-sneak is real nice for this, and has turned into one of my most-used movement commands https://github.com/justinmk/vim-sneak https://github.com/justinmk/vim-sneak > Using visual mode for moving text around: Sometimes it can be quite complicated to type the right combination of letters to cut (delete) the text I want to move around. That's where visual mode (v) shines. It highlights the selected text. I should use it more often. vim-move was a game changer for me https://github.com/matze/vim-move https://github.com/matze/vim-move > Tabs: I know how tabs work, but all the typing feels clunky. That's why I never extensively used them. Instead, I mostly use multiple terminal tabs or an IDE with Vim bindings for bigger projects. This is worth a read: https://joshldavis.com/2014/04/05/vim-tab-madness-buffers-vs-tabs/ https://joshldavis.com/2014/04/05/vim-tab-madness-buffers-vs.... Buffers + vim fzf is a really nice workflow https://github.com/junegunn/fzf.vim https://github.com/junegunn/fzf.vim
- mikekchar 8y ago
  Vim buffers are great. For me the best thing is that you can go to any buffer by ":b some-unique-part-of-the-file-path". If I'm switching between a ruby file and its spec file (tests), usually I'll just have to type ":b spec" to get there. Usually I'll have 2 open windows and will just be jumping to specific buffers all the time. I like this kind of workflow because I have poor vision and selecting from a list of files, or a list of buffers is a really painful operation for me. Instead, I'm just thinking "What do I want to work on?" and type in part of the file name/path. If I forget, I can look at the list of open buffers, but it almost never happens. One other thing I make great use of is ctags and vimgrep (just remember to use noautocmd with vimgrep so that it doesn't take a million years to parse all the files). Once I've got my working set up buffers for a problem, then it's just bouncing around inside them.
- omn1 8y ago
  OP here. Thanks for the tips. I've used vim-sneak for quite a while (it's even built into Visual Studio Code's Vim plugin), but it just didn't work with me. I'm more of an easymotion (https://github.com/easymotion/vim-easymotion https://github.com/easymotion/vim-easymotion) type of guy. But even easymotion vanished from my workflow, because `/` works almost equally well for me and easymotion is not available on every system I use. I guess what I'm trying to say is that I became more and more conservative about what external dependencies to rely on, because as soon as they become part of my workflow, I can't easily go back because they become part of muscle memory. For vim-move I use `V` + `j,k` for the selection followed by `d` to delete and `p` for paste. Works quite well for me. The problem that I have with visual selections is, that I often want to "grow" a selection from inside of my current position. Say my cursor is inside parentheses, I'd like to hit a key repeatedly to select an ever growing region of text: first the entire content inside the parentheses, then including the parenthesis, then the entire line, then the entire function and so on. Is there a plugin for that? Thanks for your article on buffers. Looks like a great workflow. What I'd like to have on top of that is a way to open a buffer based on the contents of a file. Say I have a file somewhere that contains a specific function, `myFunction()`. I'd love to just start typing `myFu` and vim would suggest the correct file to open. Bonus points for handling typos, e.g. `ymFu` should also work.
JepZ 8y ago
After using vim for a few years now, I noticed how I changed from thinking about text as characters to thinking about text as lines, which lets me create much cleaner code (independently from pretty printers). When I selected code via mouse in the past, I selected it from character to character. In vim I tend to think line-wise so I can yank, paste, delete code per line which makes sense in many scenarios.
- hzhou321 8y ago
  I have been noticing this effect as well, and I was thinking that there needs to be a change in how we design programming languages. The old programming languages are treating characters or words as atomic units, but human mind does not really work at words. We work at sentences or lines. Each line can have its own context and can host more flexible syntax. On one hand, the programming languages can be more expressive when designed toward line units -- lines naturally can host more vocabulary than isolated words; on the other hand, the compilers and parsers can actually be simpler or smarter, as lines pose boundary of syntax and errors may be confined and easy to recover.
  - earenndil 8y ago
    Lisp?
    - ludston 8y ago
      Yes and no. In my experience vim is great for manipulating s-expressions because it has expressions like da( which means "delete everything between the parens wrapping the cursor". But no, many lisp dialects have a tendency towards nesting expressions which will force them accross many lines which doesn't match up with ^^'s idea of keeping lines context free.
      - earenndil 8y ago
        Sure, but then you just say that the atomic unit is not the line, but rather a list.
linsomniac 8y ago
One thing google can do that blows most peoples mind when I show them: Did you know vim supports time travel undo? Sometimes you do some things then undo and redo trying to get back to a certain point in time. In vim you can step forward and back through all this by doing "g-" or "g+" to travel backwards or forwards in time. Or you can say ":earlier 50s" to go back to where you were 50 seconds ago. Most editors treat undo as a linear thing, you undo and you redo. But once you undo and then do some things, it starts looking more like a tree than a line. It's not frequent, but sometimes I just need to say "I know what I had was what I wanted 5 minutes ago."
- s_m_t 8y ago
  Very cool. Do you know if you can "mark" spaces in time to jump back to like you can spatially in vim? Sometimes I change a bunch of random stuff at once to try and get something to work, and perhaps this use case would be better suited to an actual git commit but I feel like a mark in time might be a good inbetween measure.
  - markrian 8y ago
    The closest thing I'm aware of is ":earlier {N}f", which "[Goes] to older text state {N} file writes before.". So once you're somewhat happy with what you've got, write the file, and then continue editing, repeat, and you can revert back to any previous saved file state.
    - s_m_t 8y ago
      Awesome, thanks
- giancarlostoro 8y ago
  All the JetBrains IDE's keep a history of your edits, I accidentally rm -rf'd the wrong dir and reverted my code back thanks to JetBrains. I can't imagine vim saving your old files that have yet to be checked in to SVN / git (breaking changes anyone?) that you've not yet opened on vim. Funny you mention that though, a coworker opens files in vim and does changes and tests but keeps it open if he's going to try something else so he can always go back to those other changes (guessing he reverts the code, then opens yet another vim window). I work with a lot of VI(M) coders but they barely take full advantage of VI(M). I just use IDE's or Emacs / VS Code (w/ X Forwarding more recently) personally makes it easier to find the fancy features with a UI. I'll share that time travel feature to my VIM coworkers maybe it'll save their tail sometime.
Theodores 8y ago
One current problem I have with Vim is those linux distributions where someone - maybe the VPS vendor/hosting company - put in some mystery .vimrc file somewhere that makes the editor apparently more friendly for new users. So you copy and paste a line to your mysql config file, to restart the database service and find that nothing has changed. So then you edit the file again and discover that the mystery .vimrc file has added a '#' at the start of the line. Another one that gets commonly messed with is the search. If you use '/' then you should expect the search to begin when you press the enter key, with the usual 'n' to go to the next match. But no, some mystery .vimrc file has made this more newbie friendly, so the search happens before pressing enter. Which is not what you want if standard, expected behaviour is expected. For reasons of teamworking I have moved away from vim plugins in the IDE, for this I have had to buy a new keyboard. Normally I do not use a full keyboard as that number block on the right hand side has no value whatsoever to me. If I was right handed and did accounts then sure, that would be a handy feature, but the number pad is really just not helping for me, most of the time, particularly on a laptop where the numpad skews the keyboard off to the left hand side. I want the spacebar in the centre, not an inch or so off skewed to one side. So my new discovery - the gaming keyboards that have the home/end and arrow keys but no number block - I think they are called 87 key keyboards. These are great if 'moving away from vim' as the 'home/end' keys make it easy to get to a start/end of a line. Under normal circumstances with vim there is no need for these extra keys, to add to the end of a line or the start is just a matter of using the right keystroke, just 'o' or 'a' is all that is needed with the magic that is vim. Moving away from vim is quite dangerous, for a while you find programs breaking because there is a block of 'kkjjj' or an 'i' embedded in there somewhere!
- wibble10 8y ago
  This can almost certainly be avoided by typing “:set paste” before entering insert mode and pasting. Give it a try!
- teilo 8y ago
  This is why I keep my vim config in GitHub. On a new server, I can be up and running in seconds.
rjkennedy98 8y ago
Surprised to see that he's gone back to an empty vimrc after years with high customization. To me customization is such a great part of vim that I can't imagine being without it. For instance, I have shortcuts to find and replace on visual selection. I also have at least 5 plugins in my vimrc that are absolutely necessary for my workflow. Pure vim is nice if you need to occasionally edit files, but if you use it as your prime editor its not enough without customization.
- JoshMnem 8y ago
  I think it needs some customization for full-time use too. Example: you can toggle comments with things like `:norm i// ` and `:norm 03x`, but with nerdcommenter, you just type `gc` or `gcu`, which requires less attention.
- aaachilless 8y ago
  My experience has also been with a decaying amount of customization. As I get better with Vim I learn more and more how to do things in a "Vim-native" manner which I had previously needed plugins for. For example, when I first started using Vim, I relied heavily on NERDTree. These days, netrw works perfectly fine for me.
  - kqr 8y ago
    This is what I tend to hear from Emacs people too. Not an absence of cpnfiguration, just a surprisingly minimal amount because to them, the defaults start making sense. I have no idea if this is because the human learns the editor, or if it is the editor shaping the thoughts of the human, but it sounds nice and I sort of wish I would get there soon.
markrian 8y ago
One built-in feature (not enabled by default) that I absolutely love is persistent undo. Love it. Basically, undo trees can be persisted across vim sessions. Have a read via ":help undo-persistence".
- nitemice 8y ago
  Pairing this with undotree[1] is really handy, as it allows you to see your full edit history, branches and all, and jump back and forth. [1] https://github.com/mbbill/undotree https://github.com/mbbill/undotree
JoshMnem 8y ago
Tabs are great for organizing groups of related files. They are different from other editors that only let you have one file per tab. With Vim you could split a tab with a frontend HTML and CSS file, and have a couple of backend files in another tab. Then `gt` or `gT` to switch between the groups. If you use nerdtree, `t` opens a file in a new tab, so you don't need to type `:tabnew` often.
alexandernst 8y ago
"And I still can't find how to quit"
- bagol 8y ago
  Did you mean, "It's hard to quit from using vim once you get accustomed to it."? :)
gwn7 8y ago
> I don't use arrow keys to move around in text anymore but forced myself to use h, j, k, l. Many people say that this is faster. After trying this for a few years, I don't think that is true (at least for me). I now just stick to it out of habit. Sounds like he's not a touch-typist. And as a general note; learning and mastering vim can hardly be a pleasant activity for non touch-typists, or otherwise typing heroes.
- keithnz 8y ago
  hjkl by themselves are probablly not a lot faster than arrow keys, after watching various people code in Vim on twitch, I notice quite a few use them like arrow keys to arrow to where they want. But it's how hjkl combo with other motions that makes getting around easy. Though I really like easymotion ( and derivitives ) for getting around to random places
- mcjiggerlog 8y ago
  I don't see why that means he's not a touch typist? I actually use both hjkl and the arrow keys. Arrow keys are useful for moving the cursor in insert mode.
  - timrichard 8y ago
    I took it to mean because hjkl are prime territory on the home row.
  - gwn7 8y ago
    Because the hjkl key bindings are invented by touch typists for touch typists. Touch typists are more comfortable with using hjkl than the arrow keys as the hjkl keys reside in the home row; so they are extremely cheaper to press than the arrow keys for touch typists. And, you don't need to move the cursor in insert mode. vim and more generally the modal editing concept is invented just so you don't do that. I'm not sure if you are a rookie vim user or have a niche use case that requires moving the cursor in the insert mode. I think it is funny that vim supports arrow keys at all. It's probably to reach a wider audience, and for compatibility. And a related fact is that the original vi doesn't support using arrow keys in insert mode in the way you expect.
bArray 8y ago
I use (Vim IMproved - not vi) vim all the time. I find it interesting to see what features other people tend to use in vim, there seems to be some minor differences in their workflows, but it's not clear who "wins" the productivity battle. I only use a very small number of it's features: * `:tabe` Create a new tab * `:e .` Start browsing files in that tab * `:w` Write the file * `:q` Quit the file (`:q!`, seriously, please do quit the file) * CTRIL+SHIFT+UP/DOWN To switch tab (doesn't reliably work on every machine) * `/WORD` To search for something * `:NUM` To go to a specific line * `i` To insert * SHIFT+V to select lines * `d` To delete lines * `x` To extract lines * `y` To "yank" (copy) lines * `p` To paste lines >Here are a few things I wish I could do better: I don't have a great memory, so memorizing more than what I use every day is a little too much. One thing that I'm working on remembering is the ability to replace strings (although I don't really like regex). >Would I learn Vim again? I'm yet to experience anything compelling enough to stray me away. The advanced features are there if I ever need them, but for the most part I am free to have a lightweight editor.
- johnboyer 8y ago
  >Vim IMproved Oh, so you are using an improved version of Vi IMproved? ;)
  - imiric 8y ago
    Emacs + evil-mode, presumably. :)
    - tom_mellior 8y ago
      I need to use Emacs rather than vim for some things (Proof General, mostly), and I was surprised how well evil-mode works. It's only undo that I don't get. From vim I'm used to be able to undo as many editing steps as I want. In evil-mode, I find that if I type "u" too many times, it runs out of undos to do and starts undoing the undos (i.e., it starts redoing things I want to go away). Also, search uses different word separators from vim: In vim "foo_bar" is a single word that will be skipped by pressing "w". But in evil-mode the "_" is a word separator, so the above is three words. That breaks my flow every time. Some of this might not be due to vanilla evil but due to the fact that I'm using it through Spacemacs. This is my two cents. If by any chance anyone would know off the top of their head how to fix these, I'd be greatful.
pera 8y ago
OP should consider using buffers: you can :ls to display the list of buffers (which I have mapped to gl) and then :bn (where n is a buffer number) to go to some specific buffer. Also, in the same fashion of gt and gT for tabs, I mapped gb to go to the next buffer, gB to the previous one, and g space to go to the last one. IIRC all these key bindings are unused by default. In my opinion tabs are more useful/interesting when you work with multiple windows layouts. https://github.com/pera/vim/blob/master/.vimrc https://github.com/pera/vim/blob/master/.vimrc
- haberman 8y ago
  I use CTRL-j and CTRL-k to cycle through my tabs. It's like j/k except for tabs instead of lines: map <C-j> :tabn<CR> map <C-k> :tabp<CR> I also alias ":split" to ":tabe", because my fingers will be forever wired to type ":split <filename>" when I want to open a new file. cnoreabbrev split tabe
- omn1 8y ago
  OP here, will try.
Zelphyr 8y ago
I read an article a few years ago, the name of which escapes me. It was something like “Idiomatic Vim” or “Linguistic Vim”. I would love to find that article again, if anyone happens to know based on the sparse info I’ve just provided, I would greatly appreciate it. One of the things I learned was that you can do things like yank to a character. In other words, if your cursor is at the beginning of “The quick brown fox jumped over the lazy dog” you can type ‘ytx’ (Yank To to the “x” next “x” character) and it’ll yank “The quick brown fo”. That’s really handy with code, I find.
- Lio 8y ago
  To sure about your article but this sort of thing is the subject https://pragprog.com/book/dnvim/practical-vim https://pragprog.com/book/dnvim/practical-vim It’s full of tips on doing things “the Vim” way without plugins.
- mangamadaiyan 8y ago
  You wouldn't happen to be referring to "Your problem with Vim is that you don't grok vi", would you? https://gist.github.com/nifl/1178878 https://gist.github.com/nifl/1178878
KasianFranks 8y ago
Vi
eadmund 8y ago
Wait until he discovers emacs! I don't mean that rudely, it's just that emacs can do everything vim does & far more.
- stewbrew 8y ago
  There is exactly one feature in emacs vim doesn't have and that's overlays. You certainly know overlays?
- kurtisc 8y ago
  Ah, but now I can use :term to run emacs inside of vim.
- falcolas 8y ago
  To paraphrase the OP's own words, he likes vim because it treats editing as a first class citizen. Editing in emacs, without something like evil mode, is a second class citizen - it requires key chords to do. And, if I put on my snark mask for a moment, at the point you're using key chords to do your editing, why limit yourself to emacs? A fully programmable editor is now the norm, not the extraordinary. Taking my snark mask back off, I realize there are no editors currently which are as fast an extensible as emacs yet; Atom is close, but bloated and slow in comparison.
FreeFull 8y ago
Nowadays, I prefer Kakoune ( http://kakoune.org/ http://kakoune.org/ ) to vim. Being based on selections rather than movements feels much nicer. It feels a bit like always being in a kind of visual mode. That said, there are the following caveats: * Vim tends to be installed/available almost everywhere, Kakoune isn't * Vim has a much bigger ecosystem * There are some very advanced features hidden in vim that most people don't know about. If you depend on those, substituting vim with another editor can be hard.
- majewsky 8y ago
  I've been meaning to look into Kakoune for some time now. How steep is the learning curve for a long-time vim user?
  - FreeFull 8y ago
    Some of the keys match up, but many are different. The actual way of thinking and composing actions while you're editing is similar, although I'd say thinking in terms of selections rather than movements makes things easier.
hungerstrike 8y ago
Whenever vim comes up I see someone trying to sell the audience on some "amazing", obscure and rarely used feature that users of other editors should be jealous of... However, it seems to me that if anyone actually wanted those features then they'd be standard in other text editors and we'd have them already. But what I find really hilarious is that whenever these features are mentioned I see people who have been using the thing for a decade say "I never knew that!" or they dicker about what the commands actually are.
daenz 8y ago
One thing I noticed when working with people who are only familiar with IDEs for coding and GUIs for version control: they're helpless on remote servers. If they need to jump on a box and debug an issue live, they just can't do it. For me, using tmux + vim + git cli locally, my workflow remains exactly the same remotely. Tools are nice, but don't let them make you weaker.
bitofhope 8y ago
Vim user here. One thing I rarely see discussed is the idea that vim is not about speed. It's about comfort. Maybe hjkl is a little faster than arrow keys. I don't care. I just like doing my editing with less hand movement. I'm sure that I could perform many operations faster with a mouse. Select text, drag it a little below. Probably faster than d}}p even. The point is, mouse is finicky and annoying. The context switch between typing and moving the mouse breaks flow. Aiming the pointer is hell, and even worse if the target is small or the mouse of low quality. Anyone who plays click-heavy video games (RTS, many MMOs, 4X) can probably understand the pain of dragging the cursor between two points and clicking repeatedly. Vim is terrible. It takes a while to learn and when you've learned it well enough you're spoiled and everything else feels painful. Vim is the closest I can get with current technology to a neurally linked brain-controlled editor. It feels like the cursor obeys my thoughts, not the limits of my manual dexterity. The next step would be an editor actually wired to my brain where I just think what the text should look like.
hajderr 8y ago
Long time Vim user here. Just switched to Emacs primarily. Use Vim for small tasks

153 points by omn1 8y ago

All of the points in the "Some things I wish I could do better" section are the reason I use a regular memorization free-ish IDE. Out of the box the things I want to do are easy (multiple files, manipulating structure of blocks of text, searching and manipulating information across my project simultaneously) and the things that aren't are rare (Add a dollar sign at the beginning of the next 13 lines). I know how to use vim solely because it's necessary to edit files in a terminal.

gwn7 8y ago
> Out of the box the things I want to do are easy Easy what? Easy to learn or easy to do? They are arguably easier to do in vim once you learn the proper method. Just not as easy to learn. That a common trade-off shared by rather elaborate tools.
- hungerstrike 8y ago
  Yeah "once you learn the proper method" is the key phrase here. The proper method being "use rote memorization to learn about things which could have easily been made available via some discoverable visual mechanism". GUIs make things easy to learn and easy to do. Especially on an OS like Windows where you can drive the entire UI with just the keyboard and about a handful of well-known keyboard shortcuts. So what's your point? Perhaps you're using a Mac or some other barely usable desktop system that has crappy keyboard acceleration for the UI?
  - gwn7 8y ago
    > The proper method being "use rote memorization to learn about things which could have easily been made available via some discoverable visual mechanism" I already said that this is a trade-off. Nobody's claiming that the vim way is the "right way" to do text editing. If you prefer a discoverable visual mechanism, you can go with it. But some people clearly prefer to "use rote memorization" because they obviously gain something out of it. And believe it or not, "rote memorization" is an essential part of our everyday life. Without it, you can do nothing. I don't see any harm in somebody deciding to apply it to text editing as well. Obviously thousands of people decided to do that, looking at vim's popularity. And lastly, the memory we are talking about here is the muscle memory. You put something there once and it's done. Using vim is very much like riding a bicyle in that sense. Would you prefer to have a bike that has labels on the pedals, brakes, gears; and prefer to go through those labels each the you need to use one of them? Memorization allows you to do things without thinking. The mantra of vim and similar tools is to enable you to become one with the tool just like you become one with your bike, your tennis racket, your sword (!), whatever. Touch typing really helps here as well. You can't understand that without investing enough time to that. (You don't have to. But you don't have to criticize it without really knowing what you are talking about either.) I use Arch Linux. Keyboard accelaration is perfect.
    - hungerstrike 8y ago
      Define rote: mechanical or habitual repetition of something to be learned. This is not something that is part of every day life at all. After school the only time I had to repeat something over and over with any kind of frequency at all was when I was learning vim. > Would you prefer to have a bike that has labels on the pedals, brakes, gears; and prefer to go through those labels each the you need to use one of them? That's not a really good analogy because my memory also works for GUI apps. However, I didn't have to use a rote method to get there. I just use the GUI with its labels and visuals helping me along the way. If I don't use something for a while, the labels and other visual elements are there to help me out. > Memorization allows you to do things without thinking. Yes and your memory works with GUIs too. But again, I didn't have to put myself through weeks of exercises to use a GUI. > You put something there once and it's done. I don't think so. Time is a thing and particularly with regards to lesser used features - you'll find yourself looking up things that you once knew. > I use Arch Linux. Keyboard accelaration is perfect. Sure it does... at least until the next update amirite?
      - deleted 8y ago
        [deleted]
      - gwn7 8y ago
        > Define rote: mechanical or habitual repetition of something to be learned. This is not something that is part of every day life at all. I can understand that. It was already clear that you are not the type to give time to learn about rather elaborate tools that have higher learning curves than the average. That's ok. It may not be a part of YOUR everyday life. But not everybody is living your life. The difference between you and me is that you are implying that vim is pointless and wrong. I'm saying that everybody should go with whatever works best for them and that every approach has their benefits. Also, attacking my operating system has nothing to do with this discussion. Not a very effective rhetorical method.
        hungerstrike 8y ago
        I agree that everybody should use what works best for them. So there’s definitely value in that. Typically when I pose an argument in a thread like this, about a technology that I don’t prefer, it’s due to the fact that a multitude of users have badgered me over my own preferences elsewhere, saying that their technology is clearly superior. I use Windows, Linux and Mac in that order of frequency and I like them all for different reasons and I dislike them all for different reasons. A ton of users on HN react badly to anyone who isn’t just like them. So, I was being a bit defensive sorry.

cgag 8y ago

It's highly overstated how hard it is to learn imo. I would learn it again without a doubt.

mattbreeden 8y ago
I ran 'vimtutor' twice and felt comfortable enough to switch. I think the only reason people think it's so difficult is they maybe try to go too deep too fast?
- remar 8y ago
  Most of the people I've talked to who gave up on trying to learn vim didn't even know vimtutor existed.
- didymospl 8y ago
  I repeated vimtutor for a few days in a row trying to following this nice Vim learning plan [1] I saw on HN and I gave up trying to switch to Vim as my main text editor after that. Even though I knew how to perform most of the basic operations, the fact I had to switch to normal mode to do anything more complex than editing of the current line felt just too unusual to me. I mean, I'm comfortable editing files on remote servers in Vim now but I don't think I'd ever be considerably more productive in Vim than in IntelliJ/Sublime. [1] https://medium.com/actualize-network/how-to-learn-vim-a-four-week-plan-cd8b376a9b85 https://medium.com/actualize-network/how-to-learn-vim-a-four...

archi42 8y ago

Regarding tabs: I bound F2 to previous tab, F3 to next tab and F4 to new tab. Besides highlighting the current line, I think this is my most important customisation.

omn1 8y ago
Oh that's cool! Think I might do that, too. Thanks.
pault 8y ago
Isn't `gt` and `gT` faster? You don't have to move your hands!
- roylez 8y ago
  It isn't. I use F11/F12 for previous/next tab, in tmux and browser, and I can confirm it.
- JoshMnem 8y ago
  I like `gt` and `gT`, because they are available out of the box on remote servers too.
  - Lio 8y ago
    Also you can use <num>gt to jumpe to, say, second tab.
- geowwy 8y ago
  `gt` will still be slow because you're using the same finger for both keys.
ropeadopepope 8y ago
I went a slightly different direction. CTRL+N is next buffer (ie: tab), CTRL+P prev buffer, LEADER+W for close buffer. I don't make new buffers a lot, so I just type out :new when I need to. Opening an existing file is LEADER+F, which opens fzy via vim-picker. I reserve the F keys for toggles. F2 is set to pastetoggle. F3 turns numbers on and off. F4 turns special characters on and off.

nurettin 8y ago

Only 10 years? Feels old, man.

keithnz 8y ago

The point in the article is that the Vim keyboard bindings are most useful. Most editors have an option or plugin for that. That's what I use mainly. For instance I use Visual Studio + Resharper + VsVim ( + AceJump + RelativeLineNumbers) as my main development enviroment. I also use webstorm configured in a similar fashion. Visual Studio and R# understands the code and how to manipulate code far better than anything in the Vim world does, but I use it in combo with Vim keyboard bindings and it becomes incredibly quick to do things. I don't actually use Vim itself very much ( I still use it for various things, but its not my main editor ). Its nicest attribute is for quick editing tasks it loads quick and can load very large files.

darthlucio 8y ago

I know you said that you like maintaining a super minimal .vimrc, but fwiw there's a couple of plugins that really helped me with the workflow issues you mentioned struggling with: > Jumping around in longer texts: I know the basics, like searching (/), jumping to a matching bracket (%) or jumping to specific lines (for line 10, type 10G), but I still could use symbols more often for navigation. vim-sneak is real nice for this, and has turned into one of my most-used movement commands https://github.com/justinmk/vim-sneak https://github.com/justinmk/vim-sneak > Using visual mode for moving text around: Sometimes it can be quite complicated to type the right combination of letters to cut (delete) the text I want to move around. That's where visual mode (v) shines. It highlights the selected text. I should use it more often. vim-move was a game changer for me https://github.com/matze/vim-move https://github.com/matze/vim-move > Tabs: I know how tabs work, but all the typing feels clunky. That's why I never extensively used them. Instead, I mostly use multiple terminal tabs or an IDE with Vim bindings for bigger projects. This is worth a read: https://joshldavis.com/2014/04/05/vim-tab-madness-buffers-vs-tabs/ https://joshldavis.com/2014/04/05/vim-tab-madness-buffers-vs.... Buffers + vim fzf is a really nice workflow https://github.com/junegunn/fzf.vim https://github.com/junegunn/fzf.vim

mikekchar 8y ago
Vim buffers are great. For me the best thing is that you can go to any buffer by ":b some-unique-part-of-the-file-path". If I'm switching between a ruby file and its spec file (tests), usually I'll just have to type ":b spec" to get there. Usually I'll have 2 open windows and will just be jumping to specific buffers all the time. I like this kind of workflow because I have poor vision and selecting from a list of files, or a list of buffers is a really painful operation for me. Instead, I'm just thinking "What do I want to work on?" and type in part of the file name/path. If I forget, I can look at the list of open buffers, but it almost never happens. One other thing I make great use of is ctags and vimgrep (just remember to use noautocmd with vimgrep so that it doesn't take a million years to parse all the files). Once I've got my working set up buffers for a problem, then it's just bouncing around inside them.
omn1 8y ago
OP here. Thanks for the tips. I've used vim-sneak for quite a while (it's even built into Visual Studio Code's Vim plugin), but it just didn't work with me. I'm more of an easymotion (https://github.com/easymotion/vim-easymotion https://github.com/easymotion/vim-easymotion) type of guy. But even easymotion vanished from my workflow, because `/` works almost equally well for me and easymotion is not available on every system I use. I guess what I'm trying to say is that I became more and more conservative about what external dependencies to rely on, because as soon as they become part of my workflow, I can't easily go back because they become part of muscle memory. For vim-move I use `V` + `j,k` for the selection followed by `d` to delete and `p` for paste. Works quite well for me. The problem that I have with visual selections is, that I often want to "grow" a selection from inside of my current position. Say my cursor is inside parentheses, I'd like to hit a key repeatedly to select an ever growing region of text: first the entire content inside the parentheses, then including the parenthesis, then the entire line, then the entire function and so on. Is there a plugin for that? Thanks for your article on buffers. Looks like a great workflow. What I'd like to have on top of that is a way to open a buffer based on the contents of a file. Say I have a file somewhere that contains a specific function, `myFunction()`. I'd love to just start typing `myFu` and vim would suggest the correct file to open. Bonus points for handling typos, e.g. `ymFu` should also work.

JepZ 8y ago

After using vim for a few years now, I noticed how I changed from thinking about text as characters to thinking about text as lines, which lets me create much cleaner code (independently from pretty printers). When I selected code via mouse in the past, I selected it from character to character. In vim I tend to think line-wise so I can yank, paste, delete code per line which makes sense in many scenarios.

hzhou321 8y ago
I have been noticing this effect as well, and I was thinking that there needs to be a change in how we design programming languages. The old programming languages are treating characters or words as atomic units, but human mind does not really work at words. We work at sentences or lines. Each line can have its own context and can host more flexible syntax. On one hand, the programming languages can be more expressive when designed toward line units -- lines naturally can host more vocabulary than isolated words; on the other hand, the compilers and parsers can actually be simpler or smarter, as lines pose boundary of syntax and errors may be confined and easy to recover.
- earenndil 8y ago
  Lisp?
  - ludston 8y ago
    Yes and no. In my experience vim is great for manipulating s-expressions because it has expressions like da( which means "delete everything between the parens wrapping the cursor". But no, many lisp dialects have a tendency towards nesting expressions which will force them accross many lines which doesn't match up with ^^'s idea of keeping lines context free.
    - earenndil 8y ago
      Sure, but then you just say that the atomic unit is not the line, but rather a list.

linsomniac 8y ago

One thing google can do that blows most peoples mind when I show them: Did you know vim supports time travel undo? Sometimes you do some things then undo and redo trying to get back to a certain point in time. In vim you can step forward and back through all this by doing "g-" or "g+" to travel backwards or forwards in time. Or you can say ":earlier 50s" to go back to where you were 50 seconds ago. Most editors treat undo as a linear thing, you undo and you redo. But once you undo and then do some things, it starts looking more like a tree than a line. It's not frequent, but sometimes I just need to say "I know what I had was what I wanted 5 minutes ago."

s_m_t 8y ago
Very cool. Do you know if you can "mark" spaces in time to jump back to like you can spatially in vim? Sometimes I change a bunch of random stuff at once to try and get something to work, and perhaps this use case would be better suited to an actual git commit but I feel like a mark in time might be a good inbetween measure.
- markrian 8y ago
  The closest thing I'm aware of is ":earlier {N}f", which "[Goes] to older text state {N} file writes before.". So once you're somewhat happy with what you've got, write the file, and then continue editing, repeat, and you can revert back to any previous saved file state.
  - s_m_t 8y ago
    Awesome, thanks
giancarlostoro 8y ago
All the JetBrains IDE's keep a history of your edits, I accidentally rm -rf'd the wrong dir and reverted my code back thanks to JetBrains. I can't imagine vim saving your old files that have yet to be checked in to SVN / git (breaking changes anyone?) that you've not yet opened on vim. Funny you mention that though, a coworker opens files in vim and does changes and tests but keeps it open if he's going to try something else so he can always go back to those other changes (guessing he reverts the code, then opens yet another vim window). I work with a lot of VI(M) coders but they barely take full advantage of VI(M). I just use IDE's or Emacs / VS Code (w/ X Forwarding more recently) personally makes it easier to find the fancy features with a UI. I'll share that time travel feature to my VIM coworkers maybe it'll save their tail sometime.

Theodores 8y ago

One current problem I have with Vim is those linux distributions where someone - maybe the VPS vendor/hosting company - put in some mystery .vimrc file somewhere that makes the editor apparently more friendly for new users. So you copy and paste a line to your mysql config file, to restart the database service and find that nothing has changed. So then you edit the file again and discover that the mystery .vimrc file has added a '#' at the start of the line. Another one that gets commonly messed with is the search. If you use '/' then you should expect the search to begin when you press the enter key, with the usual 'n' to go to the next match. But no, some mystery .vimrc file has made this more newbie friendly, so the search happens before pressing enter. Which is not what you want if standard, expected behaviour is expected. For reasons of teamworking I have moved away from vim plugins in the IDE, for this I have had to buy a new keyboard. Normally I do not use a full keyboard as that number block on the right hand side has no value whatsoever to me. If I was right handed and did accounts then sure, that would be a handy feature, but the number pad is really just not helping for me, most of the time, particularly on a laptop where the numpad skews the keyboard off to the left hand side. I want the spacebar in the centre, not an inch or so off skewed to one side. So my new discovery - the gaming keyboards that have the home/end and arrow keys but no number block - I think they are called 87 key keyboards. These are great if 'moving away from vim' as the 'home/end' keys make it easy to get to a start/end of a line. Under normal circumstances with vim there is no need for these extra keys, to add to the end of a line or the start is just a matter of using the right keystroke, just 'o' or 'a' is all that is needed with the magic that is vim. Moving away from vim is quite dangerous, for a while you find programs breaking because there is a block of 'kkjjj' or an 'i' embedded in there somewhere!

wibble10 8y ago
This can almost certainly be avoided by typing “:set paste” before entering insert mode and pasting. Give it a try!
teilo 8y ago
This is why I keep my vim config in GitHub. On a new server, I can be up and running in seconds.

rjkennedy98 8y ago

Surprised to see that he's gone back to an empty vimrc after years with high customization. To me customization is such a great part of vim that I can't imagine being without it. For instance, I have shortcuts to find and replace on visual selection. I also have at least 5 plugins in my vimrc that are absolutely necessary for my workflow. Pure vim is nice if you need to occasionally edit files, but if you use it as your prime editor its not enough without customization.

JoshMnem 8y ago
I think it needs some customization for full-time use too. Example: you can toggle comments with things like `:norm i// ` and `:norm 03x`, but with nerdcommenter, you just type `gc` or `gcu`, which requires less attention.
aaachilless 8y ago
My experience has also been with a decaying amount of customization. As I get better with Vim I learn more and more how to do things in a "Vim-native" manner which I had previously needed plugins for. For example, when I first started using Vim, I relied heavily on NERDTree. These days, netrw works perfectly fine for me.
- kqr 8y ago
  This is what I tend to hear from Emacs people too. Not an absence of cpnfiguration, just a surprisingly minimal amount because to them, the defaults start making sense. I have no idea if this is because the human learns the editor, or if it is the editor shaping the thoughts of the human, but it sounds nice and I sort of wish I would get there soon.

markrian 8y ago

One built-in feature (not enabled by default) that I absolutely love is persistent undo. Love it. Basically, undo trees can be persisted across vim sessions. Have a read via ":help undo-persistence".

nitemice 8y ago
Pairing this with undotree[1] is really handy, as it allows you to see your full edit history, branches and all, and jump back and forth. [1] https://github.com/mbbill/undotree https://github.com/mbbill/undotree

JoshMnem 8y ago

Tabs are great for organizing groups of related files. They are different from other editors that only let you have one file per tab. With Vim you could split a tab with a frontend HTML and CSS file, and have a couple of backend files in another tab. Then `gt` or `gT` to switch between the groups. If you use nerdtree, `t` opens a file in a new tab, so you don't need to type `:tabnew` often.

alexandernst 8y ago

"And I still can't find how to quit"

bagol 8y ago
Did you mean, "It's hard to quit from using vim once you get accustomed to it."? :)

gwn7 8y ago

> I don't use arrow keys to move around in text anymore but forced myself to use h, j, k, l. Many people say that this is faster. After trying this for a few years, I don't think that is true (at least for me). I now just stick to it out of habit. Sounds like he's not a touch-typist. And as a general note; learning and mastering vim can hardly be a pleasant activity for non touch-typists, or otherwise typing heroes.

keithnz 8y ago
hjkl by themselves are probablly not a lot faster than arrow keys, after watching various people code in Vim on twitch, I notice quite a few use them like arrow keys to arrow to where they want. But it's how hjkl combo with other motions that makes getting around easy. Though I really like easymotion ( and derivitives ) for getting around to random places
mcjiggerlog 8y ago
I don't see why that means he's not a touch typist? I actually use both hjkl and the arrow keys. Arrow keys are useful for moving the cursor in insert mode.
- timrichard 8y ago
  I took it to mean because hjkl are prime territory on the home row.
- gwn7 8y ago
  Because the hjkl key bindings are invented by touch typists for touch typists. Touch typists are more comfortable with using hjkl than the arrow keys as the hjkl keys reside in the home row; so they are extremely cheaper to press than the arrow keys for touch typists. And, you don't need to move the cursor in insert mode. vim and more generally the modal editing concept is invented just so you don't do that. I'm not sure if you are a rookie vim user or have a niche use case that requires moving the cursor in the insert mode. I think it is funny that vim supports arrow keys at all. It's probably to reach a wider audience, and for compatibility. And a related fact is that the original vi doesn't support using arrow keys in insert mode in the way you expect.

bArray 8y ago

I use (Vim IMproved - not vi) vim all the time. I find it interesting to see what features other people tend to use in vim, there seems to be some minor differences in their workflows, but it's not clear who "wins" the productivity battle. I only use a very small number of it's features: * `:tabe` Create a new tab * `:e .` Start browsing files in that tab * `:w` Write the file * `:q` Quit the file (`:q!`, seriously, please do quit the file) * CTRIL+SHIFT+UP/DOWN To switch tab (doesn't reliably work on every machine) * `/WORD` To search for something * `:NUM` To go to a specific line * `i` To insert * SHIFT+V to select lines * `d` To delete lines * `x` To extract lines * `y` To "yank" (copy) lines * `p` To paste lines >Here are a few things I wish I could do better: I don't have a great memory, so memorizing more than what I use every day is a little too much. One thing that I'm working on remembering is the ability to replace strings (although I don't really like regex). >Would I learn Vim again? I'm yet to experience anything compelling enough to stray me away. The advanced features are there if I ever need them, but for the most part I am free to have a lightweight editor.

johnboyer 8y ago
>Vim IMproved Oh, so you are using an improved version of Vi IMproved? ;)
- imiric 8y ago
  Emacs + evil-mode, presumably. :)
  - tom_mellior 8y ago
    I need to use Emacs rather than vim for some things (Proof General, mostly), and I was surprised how well evil-mode works. It's only undo that I don't get. From vim I'm used to be able to undo as many editing steps as I want. In evil-mode, I find that if I type "u" too many times, it runs out of undos to do and starts undoing the undos (i.e., it starts redoing things I want to go away). Also, search uses different word separators from vim: In vim "foo_bar" is a single word that will be skipped by pressing "w". But in evil-mode the "_" is a word separator, so the above is three words. That breaks my flow every time. Some of this might not be due to vanilla evil but due to the fact that I'm using it through Spacemacs. This is my two cents. If by any chance anyone would know off the top of their head how to fix these, I'd be greatful.

pera 8y ago

OP should consider using buffers: you can :ls to display the list of buffers (which I have mapped to gl) and then :bn (where n is a buffer number) to go to some specific buffer. Also, in the same fashion of gt and gT for tabs, I mapped gb to go to the next buffer, gB to the previous one, and g space to go to the last one. IIRC all these key bindings are unused by default. In my opinion tabs are more useful/interesting when you work with multiple windows layouts. https://github.com/pera/vim/blob/master/.vimrc https://github.com/pera/vim/blob/master/.vimrc

haberman 8y ago
I use CTRL-j and CTRL-k to cycle through my tabs. It's like j/k except for tabs instead of lines: map <C-j> :tabn<CR> map <C-k> :tabp<CR> I also alias ":split" to ":tabe", because my fingers will be forever wired to type ":split <filename>" when I want to open a new file. cnoreabbrev split tabe
omn1 8y ago
OP here, will try.

Zelphyr 8y ago

I read an article a few years ago, the name of which escapes me. It was something like “Idiomatic Vim” or “Linguistic Vim”. I would love to find that article again, if anyone happens to know based on the sparse info I’ve just provided, I would greatly appreciate it. One of the things I learned was that you can do things like yank to a character. In other words, if your cursor is at the beginning of “The quick brown fox jumped over the lazy dog” you can type ‘ytx’ (Yank To to the “x” next “x” character) and it’ll yank “The quick brown fo”. That’s really handy with code, I find.

Lio 8y ago
To sure about your article but this sort of thing is the subject https://pragprog.com/book/dnvim/practical-vim https://pragprog.com/book/dnvim/practical-vim It’s full of tips on doing things “the Vim” way without plugins.
mangamadaiyan 8y ago
You wouldn't happen to be referring to "Your problem with Vim is that you don't grok vi", would you? https://gist.github.com/nifl/1178878 https://gist.github.com/nifl/1178878

KasianFranks 8y ago

eadmund 8y ago

Wait until he discovers emacs! I don't mean that rudely, it's just that emacs can do everything vim does & far more.

stewbrew 8y ago
There is exactly one feature in emacs vim doesn't have and that's overlays. You certainly know overlays?
kurtisc 8y ago
Ah, but now I can use :term to run emacs inside of vim.
falcolas 8y ago
To paraphrase the OP's own words, he likes vim because it treats editing as a first class citizen. Editing in emacs, without something like evil mode, is a second class citizen - it requires key chords to do. And, if I put on my snark mask for a moment, at the point you're using key chords to do your editing, why limit yourself to emacs? A fully programmable editor is now the norm, not the extraordinary. Taking my snark mask back off, I realize there are no editors currently which are as fast an extensible as emacs yet; Atom is close, but bloated and slow in comparison.

FreeFull 8y ago

Nowadays, I prefer Kakoune ( http://kakoune.org/ http://kakoune.org/ ) to vim. Being based on selections rather than movements feels much nicer. It feels a bit like always being in a kind of visual mode. That said, there are the following caveats: * Vim tends to be installed/available almost everywhere, Kakoune isn't * Vim has a much bigger ecosystem * There are some very advanced features hidden in vim that most people don't know about. If you depend on those, substituting vim with another editor can be hard.

majewsky 8y ago
I've been meaning to look into Kakoune for some time now. How steep is the learning curve for a long-time vim user?
- FreeFull 8y ago
  Some of the keys match up, but many are different. The actual way of thinking and composing actions while you're editing is similar, although I'd say thinking in terms of selections rather than movements makes things easier.

hungerstrike 8y ago

Whenever vim comes up I see someone trying to sell the audience on some "amazing", obscure and rarely used feature that users of other editors should be jealous of... However, it seems to me that if anyone actually wanted those features then they'd be standard in other text editors and we'd have them already. But what I find really hilarious is that whenever these features are mentioned I see people who have been using the thing for a decade say "I never knew that!" or they dicker about what the commands actually are.

daenz 8y ago

One thing I noticed when working with people who are only familiar with IDEs for coding and GUIs for version control: they're helpless on remote servers. If they need to jump on a box and debug an issue live, they just can't do it. For me, using tmux + vim + git cli locally, my workflow remains exactly the same remotely. Tools are nice, but don't let them make you weaker.

bitofhope 8y ago

Vim user here. One thing I rarely see discussed is the idea that vim is not about speed. It's about comfort. Maybe hjkl is a little faster than arrow keys. I don't care. I just like doing my editing with less hand movement. I'm sure that I could perform many operations faster with a mouse. Select text, drag it a little below. Probably faster than d}}p even. The point is, mouse is finicky and annoying. The context switch between typing and moving the mouse breaks flow. Aiming the pointer is hell, and even worse if the target is small or the mouse of low quality. Anyone who plays click-heavy video games (RTS, many MMOs, 4X) can probably understand the pain of dragging the cursor between two points and clicking repeatedly. Vim is terrible. It takes a while to learn and when you've learned it well enough you're spoiled and everything else feels painful. Vim is the closest I can get with current technology to a neurally linked brain-controlled editor. It feels like the cursor obeys my thoughts, not the limits of my manual dexterity. The next step would be an editor actually wired to my brain where I just think what the text should look like.

hajderr 8y ago

Long time Vim user here. Just switched to Emacs primarily. Use Vim for small tasks