Hacker News Reader

Comment by stevebmark | Hacker News Reader

Touch typing is one way to put it. I would say Vim is an imperative editor. You need to tell the computer how to edit text by glueing together chains of small painful commands. IDEs are declarative editors, you say you want to refactor a variable, and the IDE handles it.

Vim is a text editor, not a code editor, and I keep forgetting how weird it is. "Ctrl-X Ctrl-D completes a C preprocessor macro by default" - there is no reason this should be in the core of any editor.

And finally, whatever you think of Vim, it's not worth using unless you've read Practical Vim. Without the knowledge of that book, you're too limited to approach efficient (imperative) editing.

View on HN

> And finally, whatever you think of Vim, it's not worth using unless you've read Practical Vim.

Uh, what? I find it absolutely painful to watch my coworkers click around in their IDEs. It takes them forever to get things done.

Of the handful of hard core Vim users in the office, I’m the least sophisticated. But I’m WAY faster than all the non-Vim users.

It's not so much the absence of vim as it is their apparent ignorance of the magic of hotkeys. Download a vim plugin for your IDE and you get modal editing (usually w/ vimrc binding support) too. imo that's the absolute best way to go. You get modal editing speed, modern UI, better autocomplete over a wider bank of languages, two key press project wide refactors, go to definition without needing ctags, a terminal in the ide so you can still run commands easily (typically better than vims term window does), git integration...the list goes on and on. And sure, you can download a huge set of vim plugins to get something close, but the ux will never feel as unified as it does in an ide and it takes extra work to maintain your rc+.vim...

> but the ux will never feel as unified as it does in an ide

I argue the opposite. Because vim is such a constrained environment, the UX is extremely unified.

An IDE with vim mode is the opposite. Vim mode usually only works in the text buffers and nowhere else (at least not properly). You need to memorize a combination of vim hotkeys and regular ide hotkeys OR spend a long time messing around with your IDE hotkeys (probably comparable to vim config).

In vim, since everything is a buffer and a window, you can use your regular navigation hotkeys to move between them. I just think "I want to shift my focus to the window on the left" and it doesn't matter if the window on the left is a text file or some plugin.

In something like IntelliJ, you can't "just go left". You need to know what the hotkey is for the panel on the left. The "non-modern" UI, which constrains vim actually makes a significantly more unified experience.

> terminal in the ide so you can still run commands easily (typically better than vims term window does)

This is a perfect example. How do you switch back and forth between your terminal and text file in an IDE? How do you copy paste between your terminal and text file? Can you use vim movement in your terminal that you opened in your IDE? Or your registers? In vim, that all works perfectly just like you'd expect without learning anything new, it just works like regular vim.

That being said, I still use IntelliJ if I'm writing Kotlin. The semantic analysis they can do is absolutely top notch, can't get something comparable in vim and the productivity gains out weigh my annoyance with the inconsistent UX. Something like python though? I'll probably stick with vim, jedi is good enough.

Vim binding is great and I find it solves at least 90% of my usage.

It's the 5% of vim that's unavailable (i.e. norm, macros) and 5% of needing to still click the IDE UI occasionally that reminds me that it still isn't vim.

But then again, for some language families there just isn't a choice.

I very much agree with this. It is very tedious to edit code without a "text editor". By the way, Vim and Emacs have all the fancy refactoring / formatting / navigation things that VS Code does; using the exact same implementation. You get a no-compromises best of both worlds, at the cost of a lot of front-loaded learning. (That is to say, I get why Intro to Python books don't suggest learning vim. One problem at a time. But someday, it will really help you with the mechanics of slinging code to have a featureful text editor around.)

Python without vscode and pylance is rough. And even then you need to keep up with the typehinting. Vim and python leaves me with all sorts of horrific runtime errors to debug.

Write unit tests.

I write unit tests for my personal projects - it might sounds ridiculous but it is the reason why I can grow these projects beyond the initial 12 hours of interest. Since personal project tend to be on the smaller side I usually uses typescript or python but I've never found it an issue where pure vim usage becomes an issue at scale.

It also strongly enforces separation of concern in terms of file organization. I found using vim for development to be a positive feedback loop.

Insisnwrite unit tests, but they often passed for reasons other than the intended ones because of the dynamic typing. I kept adding tests every time I caught something runtime, but I was at an order of magnitude more tests than I would need with a strong and static types language. Pylance kept me from making thos mistakes in the first place.

Vim has all the same language servers that vscode has, with all the same capabilities.

e: never mind, I see Microsoft closed sourced pylance and restricted it to their products. Typical. Of course there is still pyright along with a python language server, but I guess technically not pylance any more.

I use Pyright with Doom Emacs at work, and I have no need for anything more. And I work on a relatively large Python codebase.

Every few years I trot out some vim command new to me and it falls to the wayside. I don't even use buffers right, I use tabs. Which are apparently a bastardized version but I digress.

F f g G jkl; ESC i r R yy p and control A and control E probably cover 90% of my cases.

However. I use a nub on my ThinkPad so I have sort of instant mouse access for location things, I mostly use jumping for inside a line

Buffers and tabs serve different purposes. I think a lot of people dismiss tabs because they don't understand their purpose. It's not just about switching to different buffers quickly.

Tabs are an organized collection of windows, and you can quickly switch between them. I might organize my windows so half the screen is one buffer and on the other half, is split 3 times horizontally. Then I edit some code and realize I need to edit some other part of the codebase. I make a new tab instead of changing buffer, so I can go back to the view I setup already without having to recreate it.

Tabs are the true power of vim, I don't have that functionality in any other editor (apart from Emacs?) and I miss it constantly. Buffers aren't really a novel concept, they work the same in VS code and JetBrains IDEs.

> Tabs are the true power of vim, I don't have that functionality in any other editor (apart from Emacs?)

Yeah, Emacs also lets you do that! You can achieve similar workflows via tmux or a tiling window manager as well. It's my favorite way to work! For whatever reason I've never gone down the tiling WM rabbit hole, but I use this kind of thing in Emacs and tmux all the time.

So I do use a tiling window manager, but the problem is that to take advantage of it, I'd need the editor to put each buffer in its own (real xorg) window. I couldn't get something working with either vscode or IntelliJ.

One editor that does support it, is kakoune. I forgot about it when writing my previous comment. Each instance can connect to a server, so they can all share registers/buffers/etc. Then you can use tmux or your window manager to create the layout you want.

It's very clever, I actually think it's superior to vim, as you aren't limited to organizing your views inside a single vim "main" window. You could do stuff like kak | browser | kak, and both kak instances share everything.

Unfortunately I can't get used to the kak commands so I'll probably never change. Perhaps neovim will one day implement something similar.

Ya, "tabs" are a misnomer coming from almost any other editor which is unfortunate. Vim doesn't have what most people think of as "tabs" (I guess you could think of them as "dynamic" tabs but I digress).

Vim has been my only code editor for the past 10+ years and I wish I used tabs a little better (ie, the way you describe). As it stands I have some plugins that open in a tab so they are easy to close (like gv.vim) and otherwise use my tabline as a secondary status line (it tells me my working directory and if I'm tracking a session or not).

airline and bufferline plugins are great - it helps unify/bridge buffer and tabs

I never liked airline as I felt it was too busy and I like customizing my own statusline, though you've piqued my interest with how they deal with tabs. I actually like vim's tabs just as they are--I mostly need better mapping for manipulating them. I'm otherwise a dual-split-with-a-mark-or-two person.

Try :normal (:norm for short.) It can edit a set of lines given a certain set of vim commands. Sometimes simpler to reason with than regexes.

E.g., if you want to turn,

  * a
  * b
  * c

into,

  "a",
  "b",
  "c",

V, highlight the lines, :norm 2xi"^[A", — 2x to remove the star+space, i" to insert the quote — now we need to get out of insert mode, so that's tricky: Type ^V ESC there for verbatim ESC (I've rendered that in the command as vim will, ^[, but it will be colored to denote that it's a real ESC character) — then A", (append a quote and a comma).

You could do it with a regex, but I just find it far more natural to list the commands: my brain is already imaging it that way: remove the bullet, add the quotes and the comma.

Good for-loop for "do this to each line". Sometimes takes a bit of back & forth to construct the command, or sometimes it's just easier to do multiple :norm's. One of the best additions to my repertoire in years.

> I would say Vim is an imperative editor.

It’s interesting you say this, since I’ve always thought of it in precisely the opposite way! A traditional editor is thoroughly imperative: all editing operations are built up by sequencing basic commands, almost exclusively ‘insert/delete a character’, ‘move to this line/column’, and ‘select from line/column position X to position Y’. By contrast, Vim gives me an entire declarative language to work with text: if I want to ‘delete a word’, or ‘change the next 10 lines’, or ‘move to the previous occurrence of the identifier under the cursor’, I can just do that, without having to mentally break it up into sequences of smaller editing operations.

I suppose this all goes to reinforce a point I’ve made several times before, which is that ‘declarativity’ is more of a continuum rather than a state. Calling something ‘declarative’ without context isn’t very helpful, but it’s entirely valid to say that most text editors are less declarative than Vim, and Vim is in turn less declarative than the refactoring operations in a full-featured IDE.

My dream, as someone who writes text rather than code, is to move that next step along the continuum. I want a motion for "change sentence to future perfect tense."

That actually sounds somewhat reasonably attainable with recent advancements in natural language AI models.

> I suppose this all goes to reinforce a point I’ve made several times before, which is that ‘declarativity’ is more of a continuum rather than a state.

To me, it seems clear that editing an existing body of code is always imperative— you're literally manipulating the state of the text iteratively, no matter what you do! Code generation can be declarative. But you're still going to imperatively edit your declarations somewhere, in that case. :-P

Pretty much. I tried using vim as my sole driver for a long time then finally saw the light that modern IDE + Vim mode plugin is the one true holy path.

Vim is wonderful but a massive waste of time and the quality of plugins is just lower jn general (obv. there are several exceptions, zig language support, for instance is much better than a lot of other vim language support plugins out of the box). The modal editing can't be beat, but frankly it's just way more painful to do sophisticated things in Vim than it is in a modern IDE. At best you need to produce a write once vimscript and hook it up to a command. Contrarily the ecosystems of modern IDEs are so large there's actually a greater chance someone already solved you problem and provides it with one click/hotkey. For me, vim is nothing but a constant distraction generator. Instead of being able to focus on what I actually intended to get done I'm ever tempted to go off writing some vimscript to solve some edge case I just encountered while editing or to automate something--much better to just make it a nonoption, at least for me. I'm sure there are vim gods out there that have an entirely different experience.

I am no vim god but I have a different experience.

I've installed quite a few plugins (e.g. nerdtree, airline etc) but they are mostly cosmetic and I myself don't do much vimscript other than some basic .vimrc. But I do have most of the content of any vim cheatsheet burned into muscle memory and can come up with combination of them on the fly. I also use :norm extensively when I need to quickly batch edit anything.

I never really did encounter scenarios where the logic are so complex that I'd rather write vimscript to solve it - at worst, I'd do a macro, but combination of modal keys are usually enough. I think I find a sweet spot between using vim to its maximum utility and less about using vim for the sake of vim.

I have a quick install script for everything I depend on and one thing I found extremely valuable is the ability to pull, install and have the same editor customized and familiar in any computer, virtual or real, it even works on Windows (WSL).

It’s not an either or.

In fact, any IDE (or any coding environment) lacking VIM bindings is broken.

As long as my computer is beefy enough, I’m perfectly happy using Jetbrains or VS Code or whatever IDE, but I always use VIM bindings and it’s been a key piece of my recovery from severe RSI. It’s been a nice productivity boost, too.

>In fact, any IDE (or any coding environment) lacking VIM bindings is broken.

Not a fact. You just prefer vim bindings, which is fine. Other people prefer other schemes, which is also fine.

VIM bindings are a very, very common preference and were one of the first suggestions I got when dealing with repetitive stress injuries from extensive computer use and were key for my recovery. It was also key several others I know who have been through similar, albeit less extreme injuries.

I'm all for IDEs supporting many different bindings, but lacking VIM bindings is an accessibility issue and shuts out a significant % of the possible users.

You exhibit the “Vim mode paradox.” If you’re comfortable using the limited “Vim mode” in other editors, you don’t know Vim well enough to justify using it.

No vim mode is perfect, but they do make other editors bearable. I think vs code’s is the closest one I tried. Though I never really used it as my daily driver.

To me vim mode is just enough to keep me from ragequitting something like Xcode when using vim is practically not an option, but “vim” mode would never be enough to make me use another editor by choice. Vim isn’t just hjkl.

I tried Vim mode in XCode. When I move by paragraph, XCode crashes when it gets to the bottom of the screen.

I understand that XCode Vim mode is lacking a lot of the functionality of Vim, coming nowhere close to even the free XVim plugin. But you think they could at least make sure the few features they do include aren't completely broken.

Lolwut? I use Vim plugin for Visual Studio every day and although pretty limited compared to full fledged Vim, it's still extremely powerful. Besides hjkl movement, I still get splits, registers, macros, search/replace, formatting and the aforementioned features are easily 95% of Vim features I used to use Vim for. So the limited experience is still pretty great and I don't know how to use VS without this plugin anymore.

You've forgotten that nobody has to justify using the tools they like :)

But also, some Vi emulation modes are much, much more complete than others.

I used vim as my primary code editor for over 15 years. Now I use IntelliJ vim mode and am happy with it.

You're saying I don't know vim well enough. What important vim features (which I'd use if I knew vim) is IntelliJ missing?

> Without the knowledge of [Practical Vim], you're too limited to approach efficient (imperative) editing.

Are you the publisher or something? What a weird thing to say. I haven't read it, so I guess I'll go back to using nano--after 15 years of vim--and just suffer?

Yeah that was weird. How were we using vim for 20 years before that book ?

I have no affiliation with the book nor author. I’ve also been using Vim for about 15 years.

With LSP support VIM can do most of what you'd do in VSCode in terms of language specific refactoring. The plugin ecosystem is pretty rich.

Setting it up is still a nightmare, there are pre-made Neovim configs that I found helpful to start with (Nvchad, astrovim) but even then adding support for a new language is too much effort at times (as compared to VSCode where VSCode will suggest to download extensions the first time you open, say, a .go file and you just have to click)

VSCode with Vim bindings seems like a decent middle ground.

I've struggled with this since basically nvim started supporting LSP and few months back switched to Helix. LSP just works the way it should in vim. Sure, I am slowly rebuilding muscle memory for the Kakoune-style bindings, but it's honestly not much of a leap for having the plugins you'd install built into the editor in a cohesive way (e.g. LSP, bufferline, git gutters, unimpaired bindings).

I'm honestly shocked at how fantastic Helix is and it makes me wonder if all the toil of inheriting vim was worth it for the neovim project.

Gave Helix a try recently and liked it. Much better out of box experience.

Something like a readymade nvim config should ideally be able to provide similar experience but it's hard to not get caught up in the the quest to get it _just right_

Plus Vim keybindings are widely available in popular editors/IDEs but I think Helix bindings will take a while to get there.

Anyone who wants to get started with LSP in Vim8/9, I've found following plugins useful. a. https://github.com/yegappan/lsp [this is newer plugin and hence there few issues] b. https://github.com/prabirshrestha/vim-lsp

I recently discovered the neovim plugin for VSCode. It’s fantastic. A step up over the built in key-bindings.

What a peculiar statement. I’ve been using vim as my go-to editor for most of my 10-year career as a software developer. I am very productive. I haven’t read said book.

I haven't read it and I use Vim every day. Like any skill, just learn as you go. A couple of times a week I google for how to do something I figure is possible, then I save the link in a bookmarks folder.

I might read it at this point and learn a lot, but I'm still happy and productive with what I do know.

Vim is neither a text editor nor a code editor.

Vim is a language. To speak Vim is to speak in a way with your hands that turns words into action and moves text at the speed of thought.

I have long mastered Vim after over a decade of experience. I can barely tell you what keys I’m pressing, but when I imagine some text in my head and how I’d want to change it, I feel the force at the ends of my fingers that guides my hands until the modification is done.

Much like how you can speak to express an idea without having to think about the way your mouth moves, I can easily edit blocks of code without really knowing how my hands will move, I simply trust they will do what I need and it happens. Vim has become the interface by which my mind can directly immerse itself into the conversation of code on a screen. Most will never understand the feeling of this power unless they deliberately pursue deep mastery of Vim, but once you’ve gotten a taste of it, it becomes intoxicating.

Vim is well worth investing your time in. I guarantee it is one technology that will exist for the rest of your career. The year will be 2100, and Vim will still be around and in use by the best engineers.

What do you think of using vim plugins inside an IDE, such as IdeaVIM? How much of the benefits of what you describe do you think would remain?

I've been trying to spend more time in vim since last year because I can imagine a world with the benefits you describe, and I want to put in the long-run investment to get there. But at the same time, Vim naturally lacks the feature set of an IDE, and setting up a bunch of plug-ins so that they all work together is somewhat time consuming and brittle.

I've been wondering if I should stick to Jetbrains/VS Code and use Vim as a text manipulation language, and whether I'd still attain that editing fluency you describe.

Plug-ins are always a personal choice. For me the most essential is fuzzy finder with ctrl-P. With this I can arrive at any file or line in a massive codebase damn near instantly.

I find vim with the right plugins is as capable as any IDE, you can at least have the basics like autocomplete and various syntax highlighters and linters. Personally I think developers who lean heavily on the IDE features of more common tools are using it as a crutch for not knowing the codebase very well or language features.

Part of the journey to vim mastery is the configuration of vim until it fits you like a glove, once you’ve configured it well you rarely need to touch the config files again.

Practical Vim is worthwhile.

Unfortunately, I had to put it down to read the 695,378 word Vim manual.

Or at least, the 33,807 word core essentials.

Approachability is... not Vim.

Especially when both the manual and Practical Vim to absorb "how to use it" are a such a necessity.

I didn’t read either Practical Vim or the docs before becoming pretty proficient with Vim.

Some good blog posts and some videos did it for me. I had enough knowledge to make diving into the docs more meaningful.

Besides once you understand the language of Vim, it’s not hard to make strives.

You can get vim keybindings for Intellij so you get all the IDE stuff too.

Reply on news.ycombinator.com