I Still Use Vim | Hacker News Reader

I Still Use Vim

buttondown.email

118 pointsluu121 comments

> My vim config is 600 lines. I have fixes for small annoyances. I have a bookmarking system set up in 45 lines. I have extra syntax highlighting for code snippets that are important to me because I’m doing things the original syntax maintainers never even considered. I create impromptu keyboard mappings and abbreviations and autocommands as needed for given tasks. I can move around in the design space at will.

I use VIM on and off, but I wanted to post the above because I think it exemplifies who might like using VIM.

VIM is ideal for people who find it worthwhile to spend the time building their configuration out. VIM is the productivity tool that gets better as you put the time and effort into building it out. If you aren't the kind of person who wants to put that time and effort in, it is still decent as a basic editor, but it doesn't really shine.

I don't disagree with your thesis, but I should point out that I have been using Vim almost exclusively for almost six years now (well, NeoVim for 4 of those years), and my config is only about 40 lines, and most of it is just installing plugins for whatever languages I'm using.

Despite me not hacking it like crazy, I still think it really shines as an editor; Vim macros were sort of life-changing to me once they clicked for me. I also just think that modal editing is superior once you get past the initial learning curve.

Let me back up a step here.

I use VIM for almost all basic editing. Its muscle memory.

But for code editing, I generally end up on VSCode because it seems to have better language support. I've spent a fair amount of time with configuring VIM trying to get where I feel it needs to be. But whenever I shift to a new stack, it always seems to take an investment of time and effort to get VIM set where it's better than VSCode.

I share your experience, but it should only be a matter of time until the vim LSP clients[1] mature.

One notable exception is Go with its [vim-go](https://github.com/fatih/vim-go) plugin, which feels very mature to me as someone new to the language.

[1]: https://langserver.org/

CoC is already there:

https://github.com/neoclide/coc.nvim

Having to install node.js for a language server client is sort of a downer. For this reason I've been eagerly awaiting the built-in client in neovim, though it's definitely less polished and feature-complete than CoC today.

Isn't the "built in" neovim language server lua? I personally can't see much difference between having to install nodejs runtime Vs the lua runtime.

The difference is that the lua runtime is embedded (and wicked fast) into Neovim vs nodejs that has to go over the remote plugin interface

Fair enough. I've been using coc for a while now and can't say I've ever had any speed issues that I've noticed. But if the neocvm language server is built in and "as good" as CoC then that'll be one less plugin I'll need to install when it's ready.

Yeah I don't have any node.js speed concerns for it, I just would like to have the simplest editor microservice architecture, and putting the client to a service in a service was a bridge further than I wanted.

CoC looks neat (installing right now), but it's a perfect example of what I mean. Having to poke through and add several dozen lines to my config file to get it working.

I would love to have this functionality with just

  brew install ts-vim

And just be done with it.

I don't use vscode that much, but when I was checking it out I installed some extension which lets you edit text with true neovim (point it to a bianry) while vscode handles chrome and code understanding. Worked pretty well.

You're probably talking about Neo Vim[1] by Alexey Svetliakov. I can't recommend this one enough for a (neo)vim experience in VS Code. It is relatively new and deserves a lot more attention.

[1]: https://marketplace.visualstudio.com/items?itemName=asvetlia...

Yeah that’s the one. Love that it’s not a half baked vim emulation.

There are many ways to use vim and they're all valid! People who love barebones vim are cool. People who love configuring vim are cool. People who love embedding vim in larger programs are cool. We have way more in common than vim squabblers pretend!

Are evil users cool too?

BTW, your main point about using vim is emacs greatest strength.

You wound me greatly, but yes, evil users are cool too. I mean, I first learned vim keybindings from Kile.

(People keep telling me I'd love emacs, and I have nothing against it, I just happened to learn vim first.)

Along with Evil, Emacs org-mode is the thing that eventually lures a number of people like you over from Vim. Evil makes editing in Emacs close enough (very close) to editing in Vim. Org-mode gives useful functionality that you can't get in Vim.

So, I am now a longtime emacs (and evil, love vim-ey things) user, and I've dipped my toes in the org-mode water a few times, but it's never quite stuck.

Have you got any suggestions? The number of people that recommend it makes me sure that there's value to be had there, but it's never really become a habit for me.

The important part is to find a method and then leverage orgmode for it. With out some system is hard to make it stick.

About 40 lines sounds reasonable to me.

I've been using vim and before that other vi clones or actual vi as one of my main editors for 40 years, and my .vimrc is 60 lines.

20 of those are to automatically decrypt on read and encrypt on write .gpg or .asc files, which I copied from somewhere 20-25 years ago and haven't actually used in 15+ years, leaving only 40 lines I actually care about.

Just as an FYI, Vim has built-in support for encryption: https://vim.fandom.com/wiki/Encryption

My problem is that some of that building should've been sensible defaults, and the community tends to outsource those responsibilities to extensions.

Which means your Vim experience now has some risk of rot. Once and awhile my configurations/extensions rot and I have to go and update myself as to what happened in the ecosystem, or what is interacting with what. One day I decided I'm too tired and switched to VSC.

Also the author failed to talk about the #1 killer feature of VSC, the reason for its meteoric rise in popularity — intellisense.

Thankfully, you can get LSP-powered completion with coc.nvim, just like in VSC. It's miles better than YouCompleteMe, plus it's much easier to install—you can just use vim-plug or similar to install it.

LSP is truly one of those "rising tide lifting all boats" projects.

[0] https://github.com/neoclide/coc.nvim

I was using YCM and ALE to handle completion, but having switched to COC I won't look back. It's just a much better experience.

FWIW, neovim's built-in LSP (nvim-lspconfig -- written in Lua, currently in beta) is _outstanding_ and I have already replaced coc.nvim with it in my neovim set up. Set up is super simple, there are 2 extensions to install. Configuration is simple, I think I needed maybe 8 lines added to my `init.vim`. With that I get completion and in-line diagnostics and it's very, very fast, at least with solargraph, clangd, and tsserver.

> My problem is that some of that building should've been sensible defaults

Vim suffers a bit from the design equivalent of tech debt. Much of the defaults and common behaviors were created based on the limits of software/ hardware 30+ years ago. Those limits still affect current design.

> Also the author failed to talk about the #1 killer feature of VSC, the reason for its meteoric rise in popularity — intellisense.

Given a fairly small amount of configuration, you can get autocomplete which is nearly as good as Intellisense in VSCode. For Typescript anyhow, the autocompletion comes from the same source background process.

Agreed (though I use nvim now and thoroughly recommend it)

Vimscript is weird. Sometimes the answer to "how to do this" comes in the form of "just install this package manager...". Stop. No.

Sure, I'm ok with adding a couple of lines to vimrc, copying some files, but don't push it.

I get much more out of the box from Vscode, PyCharm, etc. Why can't it be the same with vim?

Simple. Vim is not an IDE.

If you take a step back and look at software development as a whole then IDEs like VSCode and PyCharm take the top down approach.

Whereas Vim is one of the solutions which do it bottom up.

With both approaches you can theoretically arrive at the same functionality but in reality, there will always be something missing.

Some people prefer the bottom up approach as that gives them the illusion of knowing their tool completely whereas people with the top down preference think everything is curated for them.

Over time, both kinds of people notice this isn't quite true.

This is one of the motivating forces behind nvim. While nvim supports vim script, it provides Lua as its preferred language for extension. In addition, the internal APIs are documented and are intended to be accessible from any language via RPC.

https://neovim.io/doc/user/api.html

drawing from my own experience, i once found myself trying to work on a client website. thanks to a series of events i was using termux from a cellphone. i grabbed my vimrc from my dotfiles git repo and that was that. took all of 30 seconds to turn someone's cellphone into an interface identical to the one i use everywhere else

My .vimrc is around 80 lines including 15 plugins. It's mostly like that for last 8 years. And i don't have any problem using using unmodified vi/vim on servers, which is a big plus.

So no, vim shines and it's pretty bright

My vim config is empty. I use it periodically and know the basics. I prefer it over nano and pico by a mile.

600 lines seems pretty long to me. I don't even know what I would put in a .vimrc file. Obviously I don't use it enough to even have annoyances.

The nice thing about have no config is that I can hop into vim on any computer or server anywhere and be able to use the editor. I don't have to worry about having muscle memory of using keybindings/aliases that don't exist.

> My vim config is empty.

That's the way to go. Unfortunately, most humans are fallible and I had to add a single line:

    inoremap <tab> <esc>

Mine is 3 lines. Background dark, shift width and tab spaces. Been like that for around 18 years.

I should probably add that. I know I have had it at some point on a different computer.

Mine was empty until the defaults changed in vim 8 and broke a lot of sensible behaviour.

as much as I enjoy my current job, I really want to learn new programming language/paradigm, or new skills to let me have a job with vanilla Vim without vimrc as my daily driver.

VIM is fantastic for editing files on servers for this reason.

mine is empty because i jump between so many different machines and my config is not there. so i have to remember them.

While I understand why you may want an empty config, at the same time, I don't get it. It's not a criticism.

I knew a guy that not only had no config, he didn't even use syntax highlighting, which I can't live without.

All of that power and configurability is there for a reason. My config is about 250 lines; a lot of that is just to have Vim operate like it's 2020 and not the 90's.

I'm not a C programmer, so I don't want /usr/include in my search path, which it is by default.

I want to ignore things I have no intention to edit, so I have

    set wildignore=*~,.DS_Store,.git,.hg,.svn,*.bmp,*.gif,*.gz,*.ico,*.jpeg,*.jpg,*.mp4,*.pdf,*.png,*.tar,*.webp,*.xz

Gotta have relative numbering while showing the absolute number for the current line:

    set number
    set relativenumber

I write a lot of HTML; having Emmet (see https://medium.com/vim-drops/be-a-html-ninja-with-emmet-for-...) enables me to write

     div#page>div.logo+ul#navigation>li*5>a <C-y>,

and get

   <div id="page">
        <div class="logo"></div>
        <ul id="navigation">
            <li><a href=""></a></li>
            <li><a href=""></a></li>
            <li><a href=""></a></li>
            <li><a href=""></a></li>
            <li><a href=""></a></li>
        </ul>
    </div>

Saves lots of time and keystrokes.

From .vimrc to .vim: https://vimways.org/2018/from-vimrc-to-vim/

Fabulous article that explains runtime files and why many modifications to most people's .vimrc should be in ~/.vim/.vimrc and other other runtime directories.

Lots of Vim users talk about using a minimal config because they need to access random machines that won't have their custom setup.

Or that it's some kind of badge of honor to not have any plugins, even if they could save you a ton of time and keystrokes.

Let's not forget: 1. Vim is great at remote editing, so you can use your config when updating files on servers, etc.

2. You could put your ~/.vim/.vimrc in a repo and install it anywhere you need it in like 5 minutes.

3. You could also rsync your local config to a machine if you needed to.

Of course I can use barebones Vim on some random server, but sometimes you need all the goodies with you.

The video Your Vim is only for you: (https://www.youtube.com/watch?v=6LPBpmkQdw8) reminds us that our Vim is just for us and if that means tricking it out so that it becomes our own custom editor, then so be it.

> VIM is ideal for people who find it worthwhile to spend the time building their configuration out.

I've been using VIM for over a decade and currently my customized config consists of a half a dozen tweaks, such as YAML-specific settings stashed in ./.vim/after.

If you can post it on a public repo, I'd love to see it. (same goes for the many others who use VIM as a daily driver)

The ability to customize Vim is precisely why I can't use Vim plugins for other editors. They never capture my customizations, and never offer the ability to replicate them. So I just live with non-modal editing when using other editors.

Speaking of modal editing, I'm really interested in Kakoune's model. With Vim, you type the action, then type the motion, and it performs the action immediately. This often means I have to repeat actions a few times if I'm unsure quite what motion I want, or I have to pause and count things (e.g. if I want to delete from the beginning of a token until a close paren, doing that with a single "d" command requires me to mentally balance parens to find what count I want to give to the motion). Kakoune flips this around, you do the motion first, then do the action. Of course Vim has its visual mode which is similar, but that puts you into a different mode entirely that you then have to exit if you change your mind, and not all commands work in visual mode. Kakoune also has far better support for multiple selection than Vim. The problem with Kakoune is just that I can't use it anywhere except in the terminal, which is a barrier to adopting it (whereas I use MacVim often). I'm also not sure offhand what the plugin situation is like (I know it supports plugins, but I don't know how powerful they are; I recall when kakoune first came out all extensibility was done by shelling out to external commands but I don't know if that's still the case).

Thanks for the mention of Kakoune, which I hadn't heard of. This page on its site makes a pretty interesting case for the power of its command model over vim's (though I haven't been a regular vim user for many years):

https://kakoune.org/why-kakoune/why-kakoune.html

Vim is a tool. The more knowledge you have, the more powerful it becomes.

Vim was my first editor in Linux. Before that I used Borland, VS(Visual studio) and MASM(Microsoft assembler) editors.

After learning regular expressions, I felt superman with Vim. I started doing incredible automated work that was impossible or very hard to do in anything else like VS, netbeans or whatever.

Then I learned Lisp, so I forced myself to master eMacs. It happened again, I felt super-superman once you understand Lisp and can use it to automate everything on the editor.

IDEs are great for starting to program. But if you plan on being a serious programmer I recommend that you download anki and start memorizing Vim or emacs or regular expressions commands.

That will make you also a super human, able to do things in way less time that everybody else.

“IDEs are for beginners” and “IDEs are not for serious programmers” and “Vim/Emacs make you superhuman” are myths we should not perpetuate as programmers.

I like Vim/Emacs, but they succeed in making programmers feel like magical wizards more than they succeed in making them super human.

I've also paired with vim/Emacs users who are fast at manipulating text, but terrible at all the things you can do in a couple of seconds with an IDE (rename a file/function/class/parameter and have all references update, jump to a failing test, jump to a definition of library code that isn't stored under the working directory path, structural search and replace[1], extract JSX code from the render method to create a new component etc. etc.).

For many, it's easier to add vim emulation to an IDE than it is to add the IDE features they care about to vim/Emacs. You can still be a passionate, professional, productive developer and use an IDE.

[1]: https://www.jetbrains.com/help/webstorm/structural-search-an...

>But if you plan on being a serious programmer...

Serious programmers don't say such nonsense. Serious programmers use whatever they are comfortable with. Whether it is vi or IDEA

We all start out with the same equipment; the only automation we get is muscle memory. We add software, and multiply that. If we add automation to the software, we multiply it again.

There are reasons why some people can do more than other people. Some people have natural advantages, in certain directions. Nobody has them in all directions, but automation can often compensate in the other directions.

If you don't have ambition to excel, you can stay with the minimum. If you have enough natural talent, you can play to your strengths and excel only there. It's a choice of where to invest your time and effort. It should be a conscious choice.

IDEs are a trap because they automate only certain things the IDE author thought was important, and do not reward impulses to improve in other directions.

>There are reasons why some people can do more than other people.

Yes. 80% (or more) of that is them perfecting their technique (whatever this means in each case). 15% is them spending time on what is really matters. And 5% is for the rest, including crafting or customising their tools. And in many cases you don't really need these 5%.

>IDEs are a trap because they automate only certain things the IDE author thought was important

No, human mind is a trap. IDE is just another piece of software that can be extended just as much as vim or emacs and tailored to your needs. Maybe not that easily or extensively but still.

>things the IDE author thought was important

Modern IDE's are crafted by great number of people with constant communication with their customers and industry. Obviously mass product can't be tailored for each person but you can safely say that a generalised IDE will have all things that are actually important. Everything else can be added via plugins

PS: I'm writing this as a neovim user by the way. Still think that IDEA and VSCode are the best pieces of dev software aimed for mass market out there.

Can you give an example of "super human" regular expressions?

I use regular expression search/replace (even across all files in the project) frequently in WebStorm. I'm really curious what functionality I'm missing out on.

I can boil my preferences for Vim down to a single thing that I can't find anywhere else: it's fast. I can open stupidly large files and not worry, or mash page down and have no lag. It's a pretty much invisible part of my daily workflow and any time I have tried another editor the speed is the first difference I notice and find immediately frustrating. Every other editor I have tried, even including Emacs (sorry), has at least a slight, but perceptible, difference in speed.

Yes I probably shouldn't open massive log files and hold page down, but it's nice to know that I can.

Try nvi. It'll open files vim chokes on. Try Ni string esc where N > 1000000 (insert 1000000 copies). Or however high you need to go to watch vim choke and gasp and wheeze and make you think your computer hung. Then go do the same thing in nvi and watch it happen in one second.

Likewise, find the file of size that vim can't handle on your machine, then open it with nvi.

For those virtues, speed and opening large files, nvi eats vim's lunch.

I love vim for quickly looking at files, but when it comes to working in a large codebase, I like to have a lot of information visible at once, such as having a Find panel with results, multiple files open in multiple panes, a file list, list of currently changed files, etc.

Oh, and I use proportional fonts so VIM is out.

Aside from the last sentence, I do all of those things with a combination of emacs + tmux. My workflow would easily be translated to vim. I split my screen into multiple windows each with multiple panes. Then use things like fswatch to trigger automatic execution of various things like the test runner and the build system.

What can I say, I use the mouse a lot. Despite using i3 I still rarely use shortcut keys to change focus. Then again, I shouldn't be apologetic for being a mouse user. It's just another tool.

I find moving around tmux panes kind of annoying and scrolling them even more annoying, but that's probably more of a lack of comfortability with it than anything else.

You need a

    set -g mouse on

in your ~/.tmux.conf file.

> having a Find panel with results

That feature is built into Vim with quickfix commands.

> multiple files open in multiple panes

That's also built-in.

> a file list

There's at least two built-in features that provides this, netrw and quickfix.

> list of currently changed files

That's also built-in? It's like the most basic of features.

> I use proportional fonts so VIM is out

You can use a terminal that supports it, or perhaps some NeoVim UI.

all at the same time? If out of the box VIM does all that I've certainly never found out how to do it.

Regardless, I have no plans to switch because I can't see it improving my productivity enough to justify the learning curve.

I'm not trying to convince you to switch at all. Choice of editors is just a matter of personal preference.

I'm just pointing out that all the features you've listed as lacking in Vim are built-in, widely used, and documented. And of course, these features can be used at the same time, there's nothing preventing you from doing so.

I didn't realize that git support (changed files/diffs) was built-in. I'll have to research that.

Git support, as opposed to getting a list of unsaved files, would be better served by installing vim-fugitive.

You can have multiple files open in multiple panes in Vim. It even has a built in terminal emulator, which removes most of the reasons to use tmux.

Maybe discoverability is the problem. GUI IDEs make discoverability really easy with lots of menus, settings, modals, etc. which lowers the barriers to entry and learning curve.

> I can open stupidly large files and not worry, or mash page down and have no lag.

In my experience, vim tends to start choking on files in the 100MB/1GB range.

Haha yeah that's probably close to my experience too. But I wouldn't even dare try in other editors.

My experience with vim always seems atypical when I read blog posts like this. For me it's a hard-to-kill, reliable text editor. I barely know any of the commands (despite using it for a decade) because I've honestly never felt like I was missing anything. Just having something reliably fast lets me get away with inefficiencies that are problems elsewhere. I can't stand hjkl navigation, or remember anything more complex than how to find/replace strings. But I'm perfectly happy with it just like that.

For files that big I often find myself switch back to vi. However, vi also has its limits. If the files are really huge, then grep, head, tail and awk are my best friends.

My favorite code editor by far is Vim. But I've tried newer ones over the years: Sublime, Atom, VSCode, etc. None of them seem to stick with me and I always go back to Vim. I think I've developed some sort of dependency to Vim shortcuts and on every new code editor I try I immediately install a Vim shortcuts plugin to make it feel more familiar. I still find the editors mentioned above to lack the "ease" of customization you can have with VIM. I put ease in quotes because learning vimscript is not simple, I highly recommend taking a look at https://learnvimscriptthehardway.stevelosh.com/ to learn how to do it. Thanks to that guide I was able to write my first simple plugin https://github.com/ElHacker/vim-gitstatus

I'm working on building VR applications with Unity and C#. For that task I have to say that VSCode works pretty well, it has a ton of really nice features I regularly use: like debugging unity code, autocomplete/snippets from the unity API, and my favorite Zen Mode. My biggest complain with VSCode is how slow it runs sometimes, I can type faster than VSCode refreshes which adds noise to my flow, note that I don't consider myself to be a fast typist. If they would only fix that I would be very happy with it.

To be fair I only resort to IDE's when I have to jump into a new and unfamiliar project. Once I know it well enough, I switch over to vim. Recently I got told that I might have a Stockholm syndrome. Jokes aside and all, the truth is once you learn the basic 20-30 commands, nothing will be able to match your speed.

One of the best and extremely productive programmers I have known had cerebral palsy. He typed slowly, with one finger, while holding the right hand steady with the left.

Vim and vi before it are like QWERTY keyboards: ubiquitous and productive once you memorize a 30 or so commands. I use IDEs for editing languages like Java that have a lot of dependencies but vim works for just about everything else. I don't see a compelling reason to change.

I started learning Vim in February after using VS Code/Sublime for a long time.

I wish I started learning Vim ten years ago. There's not many other things I can say that about.

Sure, someday I might switch to another primary editor or split time between a few, but learning Vim changed the way I think about editing text forever (and it's really fun).

If you need an IDE, the plugin for intellij is pretty good, even supports macros, vim-surround and some other plugins

very interesting. can you give a few examples ?

Anyone wanting to learn vim should probably start off by learning how to use vi, and then get into vim configuration. For learning vi, you can't do better than Linda Lamb's book, which you can pick up for peanuts: https://www.amazon.co.uk/Learning-Editor-Nutshell-Linda-Lamb...

Drew Neil’s “Practical Vim” is absolutely fantastic, and really explain the mindset and way of thinking to use Vim. It’s probably the best technical book I’ve ever read...

https://pragprog.com/titles/dnvim2/practical-vim-second-edit...

And of course there's the famous stackoverflow reply, "Your problem with Vim is that you don't grok vi".[1]

Reframing vi(m) usage in my head as a conversation, a linguistic back-and-forth, really helped me understand how to use vi(m) effectively.

1. https://stackoverflow.com/questions/1218390/what-is-your-mos...

Why would you learn vi when you could just learn vim?

To me that seems like saying "Anyone wanting to learn C++ should probably start off by learning how to use C".

I love vim. Easy to use, just works.

EDIT: I use Eclipse and Visual Studio code on any sort of larger project. Learning to use code completion, embedded debuggers, and embedded test tools is what makes some programmers way more productive than others. But, vim is my tools of choice for any other text editing (oh and TextMate I guess if I have to).

Not sure why the HN article opted to go for "I Still Use Vim" instead of the article title, "Why I Still Use Vim".

The former just makes you sound like an Arch Linux user.

"Why" is removed from posts by default, the submitter (or a mod) has to edit the title to reinsert it if it's correct. Same thing happens to numbers (10 Ways to ...). It's a quality of title thing, I vaguely recall but can no longer describe well the rationale for why "Why" is removed but I think it was to do with it being superfluous for many titles.

Funny enough, when I used a news aggregator I eventually decided to hide posts with titles that start with "Why" (along with a few others; I don't think I missed much).

I looked in Wikipedia and saw this: "In discussing the origins of vi and why he discontinued development, Joy said: I wish we hadn't used all the keys on the keyboard... I think as mode-based editors go, it's pretty good. One of the good things about EMACS, though, is its programmability and the modelessness. Those are two ideas which never occurred to me."

So the popular qualities of vi came into existence by accident...

Joking aside, I could never be efficient in vi or vim because I need to edit simultaneously as I type. In vim, I'm slowed down by the fear "not to mess up", since I have to switch to normal mode to edit before switching back to editing mode and continue to type. Or, for instance, in languages without a function composition operator (or pipes), typing out nested functions in order of application (which is not left-to-right) requires A LOT of switching between editing and normal modes just to complete the thought.

I've never been able to figure out how others find this desirable.

In Haskell you can use & (equivalent to OCamls |> operator) to compose the other way around.

edit: s/corresponding/equivalent/g

Once you've learned it/internalized it, there's no good reason to stop using it - it's fast, available and effective.

I hopped on the Vim train about 2-3 years ago and haven't looked back. That said, I do use VSCode with Vim key bindings more than anything. It doesn't have everything Vim does, but it does have Tim Pope's almighty surround plugin, out-of-the-box. https://github.com/tpope/vim-surround

ys2w) will put brackets around the next 2 words. That is a beautiful thing.

I'm still amazed that someone wrote a TECO macro for TECO (a line editor from the 1970's) that turned it into a screen editor. I used that macro for many years.

Oh what the heck. Here's the TECO macro for a VT52 terminal:

[4 [5 [6 [7 [8 [9 +0U7 0,0X4 10U4 [4 ETU4 [4 EDU4 [4 EUU4 [4 ^D ET&(128#64#32#1^_)#512#16#8#2ET ED"G 0ED ' @^U5/U9 ET#1ET 27^T Q9^T ET&(1^_)ET/ @^U6/.U8 ZU4 -3U6 ^^HM5 13^T ^^KM5 10^T ^^KM5 13^T :G4 < ^TU7 !F! Q7^T ZJ Q7@I%% Q7-10"E 13^T ^^KM5 -1%6 ' Q7-21"E Q6^W 0U7 0; ' Q7-127"E -D Z-Q4"N -1AU9 -D Q9-27"E 32U9 ' Q9-31"G ^^DM5 ^^KM5 1+ ' 0"E 13^T -Q6-2< ^^KM5 ^^AM5 > 10^T 13^T :G4 Q4,ZT ' ' ' Q7-27"E ^TU7 Q7-27"E !F0! 27@I%% Q4,ZX4 ^^HM5 13^T -1U7 0; ' Q7-^^?"E ^T^[ @O!F0! ' @O!F! ' > Q4,ZK Q8J Q7/ 0,0X7 G_ ^YX8 ^YK 0,0X9 ^^HM5 13^T ^^=M5 < !A! 0U4 0U6 !B! 1U5 ET#32ET ^TU7 ET&(32^_)ET Q7"L -1^W ^TU7 ' !V! Q7-127"E .-Q5"L .U5 ' -Q5D @O!A! ' Q7-31"G Q7@I%% @O!A! ' Q7-26"E 0; ' Q7-21"E 0K @O!A! ' Q7-11"E Q5K @O!A! ' Q7-8"E Q5L .-1"G 2R ' @O!A! ' Q7-4"E Q5K @13I%% 10@I%% 2R @O!A! ' Q7-3"E 0; ' Q7-27"N Q7@I%% @O!A! ' ^TU7 Q7-^^C"E Z-.-Q5"L Z-.U5 ' Q5C @O!A! ' Q7-^^D"E .-Q5"L .U5 ' Q5R @O!A! ' Q7-^^?"E ^T&31#32U7 Q7-^^0"E Q5L @O!A! ' Q7-^^1"E Q5-1"E 0U5 ' Q5J @O!A! ' Q7-^^2"E ZJ @O!A! ' Q7-^^3"E 0L @O!A! ' Q7-^^4"E -Q5L @O!A! ' Q7-^^5"E Z-.-Q5"L Z-.U5 ' Q5D @O!A! ' Q7-^^6"E @FR%% @O!A! ' Q7-^^7"E Q5< 13@I%% 10@I%% 2R > @O!A! ' Q7-^^8"E Q5P @O!A! ' Q7-^^9"E Q5-1"E ^TU5 ' Q5@I%% @O!A! ' Q7-045"E @^U4%Search: % M6"F @O!A! ' G4 ^Y-2X8 ^YK @O!S! ' Q7-^^."E 0U6 !S! Q5:@S%^EQ8%^[ Q6"N Q6^W ' @O!A! ' @O!A! ' Q7"D 0U5 < Q510+Q7-^^0U5 ^TU7 Q7"D > ' @O!V! ' 0U8 Q7-^^A"E -1U8 ' Q7-^^B"E 1U8 ' Q8"N Q5Q8U5 Q6"E 0U7 .U8 0L Q8-.%6< 0A-32"L 0A-27"N 0A-9"E 6-(Q7&7)%6^[ -2U7 ' %7 1%6 ' ' C %7 > ' Q5L -Q6U9 0U7 Q6< .-Z; 0A-32"L 0A-13"E 0; ' 0A-27"N 0A-9"E 6-(Q7&7)%9^[ -2U7 ' %7 1%9 ' ' C %7 1%9"G R ' Q9; > 0U4 @O!B! ' Q7-^^Q"E @^U4%Command: % M6"F @O!A! ' G4 ^YX9 ^YK @O!C! ' Q7-27"E 0U6 !C! ]4 Q4EU ]4 Q4ED ]4 Q4ET ]4 Q4-10"N ^O ' M9 10U4 [4 ETU4 [4 EDU4 [4 EUU4 [4 ^D ET&(128#64#32#1^_)#512#16#8#2ET ED"G 0ED ' -1EU Q6"N Q6^W ' @O!A! ' Q7-^^R"E G7 @O!A! ' Q7-^^P"E Q4"E .+1U4 ' Q5L Q4-1,.X7 Q4-1,.K G7 0U6 @O!B! ' > ET#16ET ^^>M5 ^^YM5 23+32^T 0+32^T ^^KM5 13^T !Z! ]4 Q4EU ]4 Q4ED ]4 Q4ET ]4 Q4-10"N ^O ' ]9 ]8 ]7 ]6 ]5 ]4

No, I am not trolling you, this really is a TECO macro. For some background on TECO:

https://scienceblogs.com/goodmath/2006/09/22/worlds-greatest...

> The IDE can be the “Swiss Army Knife of features” and I’m glad it’s there, just like the Victorinox I keep in my backpack.

I feel like it's the opposite, vim is my swiss army knife for working with rust or cpp or python whenever I want whereas the IDE is something I open to work on specific, more complex projects where I just care about getting something done (like my homework).

IMO neither of them are really "Swiss army knives". Multitools are pretty bad as actual tools, we just use them because carrying around an entire toolbox is nuts. It's not the versatility that makes them good, it's the form factor.

If I had to compare tech to real life tools, then IDEs would be food processors: heavy, extremely good at what they do, make some things possible and other things trivial, best at scale. And vim would be, I dunno, a really nice chef's knife? But you can't serrate a chef's knife. Whatever, analogies are dumb.

(Emacs of course would be a smart fridge running emacs as an OS.)

I only recently switched (not completely) from vim to vscode while learning a bit of web dev and rust.

I like simplicity and granular control which vim provides. At some-point I had a mouseless linux box with vi-like keybinding for everything (vimperator, muttator eg).

That said, the instant compilation and error feedback developing in rust in vscode is amazing, especially while learning.

> That said, the instant compilation and error feedback developing in rust in vscode is amazing, especially while learning

You can get pretty much the same experience in vim, using the exact same language servers as vscode. It's not even hard to setup.

https://github.com/fannheyward/coc-rust-analyzer works a treat.

One good thing to trickle down from vscode was the idea of language server protocols.

Have you tried `nvim-coc`? `coc-rls` might be a good option.

To me the biggest power of Vim is modal editing which you can now get emulated to varying degrees of completeness in your favorite editor. Whether or not a command line editor is your bag, learning modal editing and Vim keystrokes can be a huge productivity improvement and applicable to a large number of different editing environments.

Hard disagree. Modal editing makes no sense in current year. It and vi were designed for terminals without Pg Up/Down keys.[0] Looks like no End either, although there's a Home.

Times have changed. It's so awful to get used to, and the alternative is just reaching for Home/End/Pg Up/Pg Down. Gimmie a break, fam. (What's ironic is that most people I know who love vim do use those keys, so they're paying the speed penalty of not having to reach for them for nothing -- plus the million penalties of using a terminal editor, and a byzantine one at that.)

Also, ever wonder why the movement keys are HJKL and not the home row's JKL;, which would be far better and more intuitive? Glance back at that picture; for no good reason, the manufacturer of those terminals decided to put arrows on HJKL. And so, in inertial carryover of dumb design, vi's creator decided those should be the movement keys.

Sorry, time to eject from this fossilized ride from the '70s and into the 21st century.

0: http://vintagecomputer.ca/wp-content/uploads/2015/01/LSI-ADM...

Sorry to burst this bubble for you, but there was no “no good reason” to put the arrows on HJKL [1].

[1]: https://twitter.com/hillelogram/status/1326600125569961991

Text editors edit text.

Many many things that are important in life have little to do with computers. But the important things which involve computers are usually text based. You edit them with a text editor.

IDEs, at their best, edit one family of languages. At their worst: Java. They do that very well, but general purpose text editors they are not.

I recently saw Gary Bernhardt's video on Typescript(so not related to Vim) but I was astounded at his Vimfoo skills. Looks like magic. https://www.youtube.com/watch?v=GrnBXhsr0ng

I also, still use vim. Along with millions (or at least hundreds of thousands) of others I'm sure.

I'm a new gen vim user, defined as in having lived a shorter time then vim itself.

the learning cliff is significant, I've spent a whole month doing everything in vim to burn everything into muscle memory, and once that period is over, it becomes self reinforcing.

The payoff is significant, I don't leave the terminal to go to some graphic IDE anymore, unless it's Java. And my vim setup started to look more like an IDE - but an IDE that comes with the full power of vim and it's different modes. Once you get over the initial excitement over keystrokes, you'd realize that modal editing is actually the biggest draw.

People have different preferences, but for me, vim has been absolutely worth it.

It was a struggle in the beginning, often wondering why they didn’t make it like notepad.

Then came h, l, j, k and life started getting easier. Later came w, b, G, gg, c$, d^ and it clicked, that’s when it became vim for everything ascii.

The vim plugin for vscode keeps the feel going.

How can someone learn how to use/how to tweak Vim to its full capabilities? Coming from someone who does minimal tweaking on their environment beyond theming, I enjoy using Vim but always feel like I'm barely scratching the surface.

Regarding usage, you should start with the built-in vimtutor tutorial (separate binary which was most likely installed alongside vim). From there, read the manual and start looking at resources like vimcasts.org, /r/vim, _Practical Vim_, etc. _Learn Vimscript The Hard Way_ is also a great resource, but heavy on Vimscript, which you may or may not need on a regular basis. I'd argue it's worth taking a crash course so that you can try to debug third-party plugins or write your own. Really, though, the best way to learn is to jump in with both feet and search for solutions when you want to do something that you don't know how to do.

As for "tweaking" Vim, I'd suggest checking out open source vimrcs, like ThoughtBot's or Steve Losh's. You should also browse vim.org/scripts and check out plugins by people like Tim Pope and Junegunn. I can't think of any at the moment, but I know I've seen analogues to ruby-toolbox.com and clojure-toolbox.com which index plugins and let you search by topics and are a little more curated and user friendly than vim.org. You may also want to consider an opinionated Vim distribution (Janus, Space Vim, etc.), which comes with non-standard .vimrc settings and plugins.

Speaking from experience, you force yourself to use it for a period of time, preferably in a time where the task load is slightly smaller than usual. After a full month and half of this, vim commands has more or less burned into my muscle memory. This did result in many useless :wqa being typed on other software but it was absolutely worth it.

The next step is to pay attention and note when you are doing something that seems to take a lot of commands or just generally be inefficient. When you notice this happening, search docs and articles to see if there is a better way to do it.

Over time, you will accrue the things you need to know to use vim effectively.

I'd start with `vimtutor` and then there are some tutorials I wrote that start from the very beginning. (I'd greatly appreciate feedback from others).

A big tip I have is watch youtube videos and search new tweaks. While learning commands add a few on a post-it note and use that for a week. After the week is over you either learned those commands or aren't using them and don't need them.

https://stevenwalton.github.io/tutorial/vim/2019/08/31/vim-b...

There's always this classic [0].

[0] https://stackoverflow.com/questions/1218390/what-is-your-mos...

Run through the tutorial a couple times, so you learn the basics. Once you've internalized them, then start exploring the plugin ecosystem. A lot of people dive right in to customizing their vim, completely reinventing the wheel or copy/pasting configs without understanding what they do.

https://vimways.org/ is also a great resource. 'Death by a Thousand Files' in the 2018 edition is one of my favorite vim articles.

A simple method is to use it at it's simplest:

Open vim

Hit i

Type the things you need to type

Hit esc

:wq

Continue like this for a few days (maybe even map the arrow keys to hjkl, like a heretic), then I'm sure you'll think something along the lines of "hmm, I wonder how you do X in vim" learn that and continue along.

That's what I did all those years ago.

Same as most everything else.

`vimtutor` is the official starter guide

:help is an inbuilt manual, with a section for every topic you could think of

one thing i love about using Vim, may only apply to using it in a text based terminal, is that the input cursor is not the text select cursor. This may also apply to emacs. Useful in many instances to select text from one portion of a document file for copy, and to paste into another, without losing the insertion point.

Long live emacs!

Still use it more than any other program.

I would argue that, apart from startup time if your are not using the Daemon, Emacs is a great vim. The vim emulation is close to perfect.

Over the years I've been trying different editors but they're either overly complex to configure (yes I'm aware of the irony here) or I just can't make them work the way I want. I always fall back to vim, but I never top giving them a chance.

I didn't quite understand what the author meant when he said that VS Code was a 'lite' IDE. Any ideas?

I would still use Vim if it had a decent multi-caret support just like Sublime. I want alt + shift, I want ctrl + click, and I want it to just work.

If you're looking for multi-cursor support, you might want to take a look at https://github.com/martanne/vis. It doesn't support ctrl + click, but I find ctrl + n and ctrl + j go a very long way. For anything more complex, vis supports structural regular expressions.[^1] Those work for both replacement (as is customary) and for multi-caret text selection.

[^1]: These structural regular expressions took me a bit to get used to, but by now I really like the concept.

https://github.com/mg979/vim-visual-multi

Reply on news.ycombinator.com