6 ms·

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 p

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.

bradrn 4y ago
> 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.
- GavinMcG 4y ago
  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."
  - packetlost 4y ago
    That actually sounds somewhat reasonably attainable with recent advancements in natural language AI models.
- pxc 4y ago
  > 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
AlchemistCamp 4y ago
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.
- stevebmark 4y ago
  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.
  - pxc 4y ago
    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.
  - phowat 4y ago
    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.
    - eloisius 4y ago
      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.
      - bnralt 4y ago
        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.
urthor 4y ago
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.
- alwillis 4y ago
  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.
rcoveson 4y ago
> 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?
- stevebmark 4y ago
  I have no affiliation with the book nor author. I’ve also been using Vim for about 15 years.
- unsignedchar 4y ago
  Yeah that was weird. How were we using vim for 20 years before that book ?
ARandomerDude 4y ago
> 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.
- calvinmorrison 4y ago
  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
  - doix 4y ago
    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.
    - pxc 4y ago
      > 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.
cdogl 4y ago
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.
idontwantthis 4y ago
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.
narrator 4y ago
You can get vim keybindings for Intellij so you get all the IDE stuff too.
voidhorse 4y ago
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.
- Aperocky 4y ago
  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).
xwdv 4y ago
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.
- probablynish 4y ago
  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.
  - xwdv 4y ago
    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.
jatins 4y ago
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.
- pseufaux 4y ago
  I recently discovered the neovim plugin for VSCode. It’s fantastic. A step up over the built in key-bindings.
- redtriumph 4y ago
  Anyone who wants to get started with LSP in Vim8/9, I've found following plugins useful. a. https://github.com/yegappan/lsp https://github.com/yegappan/lsp [this is newer plugin and hence there few issues] b. https://github.com/prabirshrestha/vim-lsp https://github.com/prabirshrestha/vim-lsp
- jzelinskie 4y ago
  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.
  - jatins 4y ago
    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.

bradrn 4y ago

> 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.

GavinMcG 4y ago
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."
- packetlost 4y ago
  That actually sounds somewhat reasonably attainable with recent advancements in natural language AI models.
pxc 4y ago
> 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

AlchemistCamp 4y ago

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.

stevebmark 4y ago
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.
- pxc 4y ago
  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.
- phowat 4y ago
  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.
  - eloisius 4y ago
    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.
    - bnralt 4y ago
      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.

urthor 4y ago

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.

alwillis 4y ago
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.

rcoveson 4y ago

> 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?

stevebmark 4y ago
I have no affiliation with the book nor author. I’ve also been using Vim for about 15 years.
unsignedchar 4y ago
Yeah that was weird. How were we using vim for 20 years before that book ?

ARandomerDude 4y ago

> 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.

calvinmorrison 4y ago
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
- doix 4y ago
  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.
  - pxc 4y ago
    > 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.

cdogl 4y ago

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.

idontwantthis 4y ago

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.

narrator 4y ago

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

voidhorse 4y ago

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.

Aperocky 4y ago
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).

xwdv 4y ago

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.

probablynish 4y ago
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.
- xwdv 4y ago
  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.

jatins 4y ago

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.

pseufaux 4y ago
I recently discovered the neovim plugin for VSCode. It’s fantastic. A step up over the built in key-bindings.
redtriumph 4y ago
Anyone who wants to get started with LSP in Vim8/9, I've found following plugins useful. a. https://github.com/yegappan/lsp https://github.com/yegappan/lsp [this is newer plugin and hence there few issues] b. https://github.com/prabirshrestha/vim-lsp https://github.com/prabirshrestha/vim-lsp
jzelinskie 4y ago
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.
- jatins 4y ago
  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.