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.
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
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.
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.
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.
Not a fact. You just prefer vim bindings, which is fine. Other people prefer other schemes, which is also fine.
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.
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.
But also, some Vi emulation modes are much, much more complete than others.
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?
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?
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.
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.
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.
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
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.
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.
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.
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).
E.g., if you want to turn,
* a
* b
* c
"a",
"b",
"c",
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 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.
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 might read it at this point and learn a lot, but I'm still happy and productive with what I do know.
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'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).
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.
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.
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.
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'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.
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.
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.