What Is Vim?(blog.jonas.foo)
blog.jonas.foo
What Is Vim?
https://blog.jonas.foo/whats_vim.html
178 comments
There's a vscode extension that embeds NeoVim and just uses VSCode UI as a front end to delegate key presses to:
https://github.com/vscode-neovim/vscode-neovim
This yields a better experience than the old half baked VSCode vim emulation.
https://github.com/vscode-neovim/vscode-neovim
This yields a better experience than the old half baked VSCode vim emulation.
This setup 'just' works for me. I have mapped certain functionality, for e.g. toggling the file explorer to a nvim keymap (the extension also enables h, j, k, l, y, p, etc. commands in the explorer) but I use the cmd/ctrl + P keymap for searching files in the current project, so it feels incomplete sometimes. When I am editing a set of files it works great, but as soon as I use a VS code feature, for e.g. project search, the experience is okay and may require a mouse, which is not surprising but I hope the integration gets even better.
I am sure that with more configuration, the experience could be made more NeoVim like but I don't know whether I should spend time doing this or invest my time learning/adapting to a terminal based flow for the few tasks for which I am used to the VS Code GUI (browsing Git history, diffs for pull requests, git stash operations, debugging).
I started with a base config (kickstart.nvim) after trying out LazyVim sometime back, but kept going back to VS Code for some of the tasks. So what I have now is not significantly better but I like it.
I am sure that with more configuration, the experience could be made more NeoVim like but I don't know whether I should spend time doing this or invest my time learning/adapting to a terminal based flow for the few tasks for which I am used to the VS Code GUI (browsing Git history, diffs for pull requests, git stash operations, debugging).
I started with a base config (kickstart.nvim) after trying out LazyVim sometime back, but kept going back to VS Code for some of the tasks. So what I have now is not significantly better but I like it.
I tend to agree with this, but I went in the reverse direction. I started out with kickstart.nvim and moved to LazyVim when I saw what Folke was doing with it. It's an excellent config and rarely chokes on large files or breaks, even though the development is very rapid.
I used this for a few months and went back to the vim emulator [1]. I can't recall what but some of the things kept breaking in Neovim. And the frequent, near daily extension updates were annoying.
1. https://marketplace.visualstudio.com/items?itemName=vscodevi...
1. https://marketplace.visualstudio.com/items?itemName=vscodevi...
>And they’re always frustratingly incomplete and/or buggy.
My favorite is all the applications which have a vim mode and are clearly done by people who think that just means making hjkl act like arrow keys and adding in a few single key commands. I wish more people would take the time to understand what modal editing actually is.
In a project of mine which has an editor that is pretty much vim with a few modifications to suit my purposes and slimmed down to just the needed features, I added an optional emacs mode which can be enabled with C-M-e M-S-m, it enables emacs in evil mode.
My favorite is all the applications which have a vim mode and are clearly done by people who think that just means making hjkl act like arrow keys and adding in a few single key commands. I wish more people would take the time to understand what modal editing actually is.
In a project of mine which has an editor that is pretty much vim with a few modifications to suit my purposes and slimmed down to just the needed features, I added an optional emacs mode which can be enabled with C-M-e M-S-m, it enables emacs in evil mode.
One day during my vim journey I discovered filters and realised I could turbo charge my editing by running selections through any and all of unix and now I don't need fancy spacing plugins - I have `column` and I can `sort`
This then allowed me to golf a one line vim macro that shells out a selection to nc which connects to a clojure socket repl
I don't think many "vim modes" would allow that. The most earnest of vim modes is probably evil mode. Of course, only your true mortal enemy could ever understand you...
This then allowed me to golf a one line vim macro that shells out a selection to nc which connects to a clojure socket repl
I don't think many "vim modes" would allow that. The most earnest of vim modes is probably evil mode. Of course, only your true mortal enemy could ever understand you...
> And they’re always frustratingly incomplete and/or buggy
I refer to this as the Vim Uncanny Valley
I refer to this as the Vim Uncanny Valley
Feature request: `:vuv` causes vim to replace native operation by a broken, buggy half-implementation. Optional enhancement: LLM learns your favorite commands, and makes sure that they specifically are broken.
> > There's a Vim mode in every single mainstream code editor out there.
Sadly, because of the unchecked proliferation of apps added to the software enterprise, this is not really true. A "modern" software organization probably has something like: Notion, Gdocs, Paper, Slack, Figma, Jira, and Github. If they have vim mode at all, (most don't) they require learning entirely new UI patterns for each app - the sheer waste is astounding. I'd love to be able to say "I've got a professional editing environment set up that's highly efficient for me to write both code and prose. Can I, like, use my tools and edit text?". But the answer is always "No - we must scatter our thoughts as far and wide using as many tools as possible!" The lack of a workable vim mode makes the problem worse.
Sadly, because of the unchecked proliferation of apps added to the software enterprise, this is not really true. A "modern" software organization probably has something like: Notion, Gdocs, Paper, Slack, Figma, Jira, and Github. If they have vim mode at all, (most don't) they require learning entirely new UI patterns for each app - the sheer waste is astounding. I'd love to be able to say "I've got a professional editing environment set up that's highly efficient for me to write both code and prose. Can I, like, use my tools and edit text?". But the answer is always "No - we must scatter our thoughts as far and wide using as many tools as possible!" The lack of a workable vim mode makes the problem worse.
And then they hand-wring about silos. The level of slop at software companies is astounding. Let’s drop everything to make sure we’re writing the backend and frontend in the same language, and then half-document everything over Slack, Confluence, README.mds, and GitHub wikis.
Confluence is especially stupid to me when everything happens on GitHub anyway, and most companies do GitOps in one form or another. We can literally colocate documentation next to the same code files it applies to, using a nice terminal friendly markup language. Most programming languages these days allow us to write Markdown documentation inline next to the declaration it applies to. But no, let’s use Atlassian’s bespoke proprietary Enterprise Offering of a rich text editor. Disgusting.
But hey, suits need to sell their enterprise software to somebody.
Confluence is especially stupid to me when everything happens on GitHub anyway, and most companies do GitOps in one form or another. We can literally colocate documentation next to the same code files it applies to, using a nice terminal friendly markup language. Most programming languages these days allow us to write Markdown documentation inline next to the declaration it applies to. But no, let’s use Atlassian’s bespoke proprietary Enterprise Offering of a rich text editor. Disgusting.
But hey, suits need to sell their enterprise software to somebody.
I’m using GhostText/AtomicChrome to edit any browser test field using a real editor (in my case Emacs). I recommend trying it if you have this challenge.
vim in obsidian?
> And they’re always frustratingly incomplete and/or buggy.
Have you tried evil-mode (Emacs VI Layer - E.V.I.L.), an implementation of the vim-bindings in Emacs? I've heard it works very well.
Or, at least, the Emacs subreddit seems to get a pretty steady flow of people who come from vim and get into Doom Emacs, which has evil-mode (and lots of other stuff) pre-configured and ready to go.
They seem very happy, from reading their reports, anyway.
Have you tried evil-mode (Emacs VI Layer - E.V.I.L.), an implementation of the vim-bindings in Emacs? I've heard it works very well.
Or, at least, the Emacs subreddit seems to get a pretty steady flow of people who come from vim and get into Doom Emacs, which has evil-mode (and lots of other stuff) pre-configured and ready to go.
They seem very happy, from reading their reports, anyway.
evil on Emacs has been great for me. I’ve been using vim for 20 years (vim, visual studio, vim again, now Emacs) and Emacs/evil for at least 5 years or so.
I’ve heard someone say that Emacs with Evil is a better vim than vim. I’m inclined to agree.
I’ve heard someone say that Emacs with Evil is a better vim than vim. I’m inclined to agree.
Ok, it's settled then! OP should have said:
"And they - vim implementations - are always frustratingly incomplete and/or buggy...
Except perhaps Emacs' evil-mode, with some users going so far as to claim that it's an even better implementation of vim-bindings than vim!"
:=D
P.S., off the back of your comment, I downloaded and started playing with Doom Emacs last night, as this thread reminded me of how great some people claim Doom and the vim bindings are. My Emacs has been stable for a while, with a basic enough configuration (only a thousand lines hah), so I'm in the mood for playing with some alternatives.
Being able to test very different configs now with "--init-directory" is really a nifty quality of life improvement which I had yet to fully appreciate!
"And they - vim implementations - are always frustratingly incomplete and/or buggy...
Except perhaps Emacs' evil-mode, with some users going so far as to claim that it's an even better implementation of vim-bindings than vim!"
:=D
P.S., off the back of your comment, I downloaded and started playing with Doom Emacs last night, as this thread reminded me of how great some people claim Doom and the vim bindings are. My Emacs has been stable for a while, with a basic enough configuration (only a thousand lines hah), so I'm in the mood for playing with some alternatives.
Being able to test very different configs now with "--init-directory" is really a nifty quality of life improvement which I had yet to fully appreciate!
Hah. Yes, --init-directory is very useful.
I think Doom is a fantastic way to get started and know what's out there. I do suggest folks to eventually dive into building their own config. Having that much control over your work surface is where Emacs and its users can really shine, I think. It's a commitment though.
I think Doom is a fantastic way to get started and know what's out there. I do suggest folks to eventually dive into building their own config. Having that much control over your work surface is where Emacs and its users can really shine, I think. It's a commitment though.
This is my current setup, and I love it.
To me it brings together the best of vim with the richness of Emacs.
Setting up Emacs from scratch is quite the project though if you want all the bells and whistles
Setting up Emacs from scratch is quite the project though if you want all the bells and whistles
To get all the bells and whistles done oneself, yes, it is time and learning.
Using Emacs with no bells and whistles just for writing is very enjoyable too, though! That's how I started. Within an hour or two I'd removed any visual clutter from the screen, and put on some dark theme (just clicking around the menu bar).
M-x help-with-tutorial (which came up when I first ran it, and I said oh, what's that), and that was me gone!
For weeks and weeks all I did was pump out text files with no formatting, being amazed that I could jump forward and backwards over words, sentences, and lines. It was an absolute joy, with a warm feeling of clarity and clean-ness to it.
Using Emacs with no bells and whistles just for writing is very enjoyable too, though! That's how I started. Within an hour or two I'd removed any visual clutter from the screen, and put on some dark theme (just clicking around the menu bar).
M-x help-with-tutorial (which came up when I first ran it, and I said oh, what's that), and that was me gone!
For weeks and weeks all I did was pump out text files with no formatting, being amazed that I could jump forward and backwards over words, sentences, and lines. It was an absolute joy, with a warm feeling of clarity and clean-ness to it.
This ctrl+w shortcut gets me all the time when using a web based Spice session to work on VMs and the experience is similar to getting wired earphones yanked out of your ear. There might be a way to inhibit this behavior but I never looked into it because I use it to close browser tabs too.
> In VS Code, it maintains its own undo stack, and the interactions between the two undo stacks are terrible and terribly frustrating
That’s because Vim has a more sophisticated undo stack than VS Code.
Vim keeps its history as a tree where you can jump between branches.
That’s because Vim has a more sophisticated undo stack than VS Code.
Vim keeps its history as a tree where you can jump between branches.
It’s not about stack versus tree; it’s about the granularity of changes and what causes actions to be pushed to the undo stack (where there’s a pretty fundamental difference between modal and non-modal editors), and the fact that I suppose VS Code just doesn’t let extensions directly manipulate the undo stack in the way required.
Look through https://github.com/VSCodeVim/Vim/issues?q=undo, there’s a lot. VSCodeVim tries to make it behave more like Vim, and because it’s independent of the native undo stack, it’s frequently a miserable experience. Pretty sure I disabled it, when I tried using VS Code for a short while and with Vim mode.
Look through https://github.com/VSCodeVim/Vim/issues?q=undo, there’s a lot. VSCodeVim tries to make it behave more like Vim, and because it’s independent of the native undo stack, it’s frequently a miserable experience. Pretty sure I disabled it, when I tried using VS Code for a short while and with Vim mode.
That's been my experience as well. I tried a few times to make my regular vim bindings + plugins to work in Rider and there's always that last 5% that seems to not work quite the way you'd expect, even for supported plugins. Bummer.
For me, they’re unusable. Many have tried to shoehorn Vim mode into other editors. It just doesn’t fit, degrade both developer experience and the editor itself
Can you give example of vim features that you miss in the vscode plugin? Mainly because I likely don't know about them and I would like to add them to my toolkit (the surround thing is not a vim feature, it is a plugin, although the vscode plugin has that too)
The "buffer" model. Half the speed of using vim in a project for me is the ability to manipulate the layout and having different "windows" on the same file. One of my most common workflow is to split the current window and navigate to a different part of the same file for reference purpose (can quickly switch to another file with fuzzy finding too).
And quick integration with external tooling. Creating an extension for vscode is cumbersome.
And quick integration with external tooling. Creating an extension for vscode is cumbersome.
This works the same in vscode as it does in vim as far as I am aware. e.g. `:vs` to split the window and moving between windows uses the same shortcuts as it does in vim.
The fundamental difference is that in Vim, a tab/window contains splits, whereas in VSCode and every other editor AFAIK, a tab is a child of a split.
In Vim I can have test and implementation side-by-side in tab0, and then two splits of the one file in tab1, a header file, impl and test in tab2, etc.
With another editor, I have to switch tabs in split 1, then switch tabs in split 2, rearranging or adding more splits as needed when moving between different groups of files.
In Vim I can have test and implementation side-by-side in tab0, and then two splits of the one file in tab1, a header file, impl and test in tab2, etc.
With another editor, I have to switch tabs in split 1, then switch tabs in split 2, rearranging or adding more splits as needed when moving between different groups of files.
It's night and day. Vscode was never meant for the workflow, so even small things like moving to the sidebars and interacting with them using the keyboard is a pain in the ass.
Setting up custom hotkeys is an exercise in patience, and you are constantly fighting with native hotkeys that try to do the same thing.
I tried making vim mode work for years and I always go back to the original because it's where I'm at home
Setting up custom hotkeys is an exercise in patience, and you are constantly fighting with native hotkeys that try to do the same thing.
I tried making vim mode work for years and I always go back to the original because it's where I'm at home
It’s been a long time since I used vscode (~5 years) so my experience may be out of date. But I recall the vim plugin missing the quickfix list and :cdo. Also there were quirks with y and p that didn’t happen when using vim (maybe extra whitespace getting inserted).
Region select. Custom keybindings. Macros.
All of those are available in the vscode plugin.
last time i used it, the keybindings were really buggy and I found myself falling back on my mouse much more often than I expected to.
Both the VSCode vim extension and the IdeaVIM plugin for Intellij support surround.
There's still some plugins that I miss in those implementations, but both projects are gradually adding support for more.
Yep, it's apparently easier to move your IDE into vim than it is to move vim into your IDE.
The only vim mode I've met that wasn't infuriatingly incomplete was emacs evil mode.
The only vim mode I've met that wasn't infuriatingly incomplete was emacs evil mode.
vrapper (vi mode for eclipse IDE plugin), have a similar issue. Usually don't have problems, but sometimes, both undo stacks begin to do very weird things.
However, when I tried VS Code vim mode, I found far better than Vrapper or Kate vim mode.
However, when I tried VS Code vim mode, I found far better than Vrapper or Kate vim mode.
Yeah when you live in vscode vim mode you learn to completely avoid certain vim features
Vim is not only an editing language, but a fast-starting editor with a small-ish native executable, and small run-time memory use.
This facet is typically not ported into other editors that have a Vim mode.
Vim runs natively inside virtual machines and containers, on resource-constrained embedded systems, and on remotely accessed machines.
Another aspect is that Vim can be operated entirely using a terminal emulator, and so can be running on a remote host to which the use only has a SSH or serial connection.
This facet is typically not ported into other editors that have a Vim mode.
Vim runs natively inside virtual machines and containers, on resource-constrained embedded systems, and on remotely accessed machines.
Another aspect is that Vim can be operated entirely using a terminal emulator, and so can be running on a remote host to which the use only has a SSH or serial connection.
Well said. I use nvim with all kinds of plugins and a custom init.lua, and then I use vim (or nvi) when something goes wrong with my init.lua, and nvim won't start, or when I want to quickly open a file really quickly and not wait the second or so it takes for my nvim setup to load.
Likewise, vim lets me do local editing on any system I connect to as there's rarely ever a Unix left that doesn't have vim installed. (Back when vim was the new kid on the block, I said the same thing about stock ex/vi - I made sure I was comfortable editing in vi, and then I never felt uncomfortable when I had to do work on a remote system.)
Another benefit with vim or nvim is how easy it is to copy someone else's full-featured setup: one of the programmers I work with is really into nvim, and he figured out an ideal setup for both working on Go and Python code. Then he just shared his setup with me. Copying someone's VSCode setup with plugins and all and getting it all to work would be a multi-hour ordeal.
Likewise, vim lets me do local editing on any system I connect to as there's rarely ever a Unix left that doesn't have vim installed. (Back when vim was the new kid on the block, I said the same thing about stock ex/vi - I made sure I was comfortable editing in vi, and then I never felt uncomfortable when I had to do work on a remote system.)
Another benefit with vim or nvim is how easy it is to copy someone else's full-featured setup: one of the programmers I work with is really into nvim, and he figured out an ideal setup for both working on Go and Python code. Then he just shared his setup with me. Copying someone's VSCode setup with plugins and all and getting it all to work would be a multi-hour ordeal.
I believe you can use `nvim --clean` to ignore your config files.
Would you mind sharing the python setup? So many options and it’s overwhelming for someone looking to switch from vscode.
I copied this guy's Python setup:
https://github.com/samuellwn/myconfig
The relevant stuff is under "nvim". If you do a lot of Python development, the rest of his "myconfig" might be useful to you too.
https://github.com/samuellwn/myconfig
The relevant stuff is under "nvim". If you do a lot of Python development, the rest of his "myconfig" might be useful to you too.
nvim/.config/nvim/lua/plugins
- `blink.lua` (auto complete drop-down) - `dap.lua` (debugger) - `lsp.lua` (language server ruff and pyright setup)
- `blink.lua` (auto complete drop-down) - `dap.lua` (debugger) - `lsp.lua` (language server ruff and pyright setup)
https://github.com/KingMichaelPark/dotfiles/tree/main/nvim/....
(Forgot the link)
The reason I chose Vim over Emacs is simply because of the fact that it's available literally EVERYWHERE. I've honestly never seen a UNIX system which doesn't have Vi or Vim installed by default. Emacs is more hit and miss.
You should read the article. Vim does run everywhere, including inside Emacs. You don't "choose vim over Emacs," you choose vim, and optionally Emacs if you want to use Emacs in whatever context. evil-mode is a great vim; using that won't stop a vim user from using native C vim instead of emacs lisp vim when logged into a remote system
(source: vim user for twenty years, Emacs ten)
(source: vim user for twenty years, Emacs ten)
> literally EVERYWHERE
Chrome and youtube also support some of the common vi/vim navigation keys.
Chrome and youtube also support some of the common vi/vim navigation keys.
What does Vim offer over Nano?
After using both I settled on Nano years ago and still don't see how my workflow would improve with Vim.
After using both I settled on Nano years ago and still don't see how my workflow would improve with Vim.
No one is trying to convince you to use Vim over Nano. Use whatever makes you productive
I think you have to see someone who has used it for a while (or use it for a while yourself) to understand.
To me nano is just a basic text editor (open, edit, save). Vim is a way to 'jack in' and be able to manipulate text with my mind. I don't 'think' anout how to accomplish something, I just think about what I want done and my hands just do it.
This comes from the modal nature of the editor and text objects, mostly, but there are so many other little things (like macros, ex commands, filters) that you pick up over time that all add up to a great text manipulation toolkit.
To me nano is just a basic text editor (open, edit, save). Vim is a way to 'jack in' and be able to manipulate text with my mind. I don't 'think' anout how to accomplish something, I just think about what I want done and my hands just do it.
This comes from the modal nature of the editor and text objects, mostly, but there are so many other little things (like macros, ex commands, filters) that you pick up over time that all add up to a great text manipulation toolkit.
Are you being serious? Vim offers so much more advanced features. But if you don't have a use for those advanced features of Vim Nano is probably more than enough for your use case. I just find Vim more enjoyable to use even for simple tasks since the commands are already in my brain and I really prefer the modality.
guy has a seriously simple use case
Well. There is nano as well
In the Linux world, sure. The only reason why I've seen nano (rather, pico) on many non-Linux systems was because pine was installed, and that was only on multi-user systems.
I used Pine, but with Vim as an external editor. Pico was not suitable for composing and replying to e-mails.
On a personal level, I am not going to disagree with you. I configured Pine to use vi (or whatever vi variant shipped with AIX). I also seem to recall configuring lynx to use vi to edit forms (which made using web based forums bearable).
That said, editors are a personal thing. Pico was certainly a better choice for most people. In most cases, their needs are basic. Pico also displayed the relevant keyboard shortcuts on the bottom of the screen. Why would they want to complicate things, and vi would complicate things for people who did not have a need for a text editor outside of composing emails.
That said, editors are a personal thing. Pico was certainly a better choice for most people. In most cases, their needs are basic. Pico also displayed the relevant keyboard shortcuts on the bottom of the screen. Why would they want to complicate things, and vi would complicate things for people who did not have a need for a text editor outside of composing emails.
> but a fast-starting editor with a small-ish native executable, and small run-time memory use.
In spite of these so-called "flaws", I still prefer Emacs!
In spite of these so-called "flaws", I still prefer Emacs!
I use Emacs with Evil. But for looping macros on big files I use Neovim.
Zed feels quite as fast as vim though, and has remote ssh for remote hosts
And you don't have to suffer latency when working on machines with 300ms latency
I still use vim when I need to quickly edit some file on some remote host once, but for see no reason to use it over zed in other cases
And you don't have to suffer latency when working on machines with 300ms latency
I still use vim when I need to quickly edit some file on some remote host once, but for see no reason to use it over zed in other cases
There are two main camps of editor user: habitual adopter and entrenched.
Habitual adopters tend to jump from editor to editor, for myiad reasons. Entrenched users tend to dig in and try to learn their editor when they hit snags.
Vim amd Neovim are great for the entrenched type of user. There is so much depth to the editor, but it is not immediately obvious. Habitual adopters tend to discard Vim when a new editor gets a little traction.
Habitual adopters tend to jump from editor to editor, for myiad reasons. Entrenched users tend to dig in and try to learn their editor when they hit snags.
Vim amd Neovim are great for the entrenched type of user. There is so much depth to the editor, but it is not immediately obvious. Habitual adopters tend to discard Vim when a new editor gets a little traction.
IME, vim is also easier to compile statically than nvi and other vi clones that are actually smaller than vim.
Learning Vim early on had a high return on investment for this reason. Years later, I'm still able to benefit from the same muscle memory in modern tools, e.g. Obsidian.
It should be said, though, that most implementations are simplified rewrites of Vim's core functionality. When you use a tool to achieve a sense of "flow", it can be grating for the editor to behave in subtly different ways from expectation, or discover an important feature does not work at all. Also, there tends to be limited, if any, support for Vim plugins.
In the modern era of Vim and NeoVim, it's possible for such tools to use the real version via network protocol, but integration is easier said than done. So far it's mostly been Vim GUI wrappers that leverage the capability rather than independent editors.
I still use Vim mode where I can even if it's a shadow of the real Vim experience. It makes life easier to use the same muscle memory on every shell, editor, and command-line, and not have to worry about learning every new app's idiosyncracies.
It should be said, though, that most implementations are simplified rewrites of Vim's core functionality. When you use a tool to achieve a sense of "flow", it can be grating for the editor to behave in subtly different ways from expectation, or discover an important feature does not work at all. Also, there tends to be limited, if any, support for Vim plugins.
In the modern era of Vim and NeoVim, it's possible for such tools to use the real version via network protocol, but integration is easier said than done. So far it's mostly been Vim GUI wrappers that leverage the capability rather than independent editors.
I still use Vim mode where I can even if it's a shadow of the real Vim experience. It makes life easier to use the same muscle memory on every shell, editor, and command-line, and not have to worry about learning every new app's idiosyncracies.
Long ago, I learned video editing on a CMX tape based system. The key bindings on that system remain in place in pretty much every video application today. (Spacebar => play/pause, j/k/l => reverse/stop/forward, i/o => in/out) Sometimes, keybindings just make sense and for them to not do it definitely as you say feels disturbing. For new apps that don't, it's like did you live under a rock in a cave and never see any other preceding program that you are making, or do you honestly think yours is better. I can assure, they aren't.
Never touched a CMX, with the EditDroid being the oldest I ever saw and it had a trackball/scrub knob.
But the vi keybindings are directly from the LSI ADM 3A terminal, which is what Bill Joy wrote vi on.
It had overloaded hjkl for the arrow keys compared to it's predecessors like the 7700A and successor 3A+ that had dedicated arrow keys.
The fact that Home/~ were the same key thus ~ being your home directory and that esc was where the tab key is on modern keyboards explains a lot about the vi keybindings.
But the vi keybindings are directly from the LSI ADM 3A terminal, which is what Bill Joy wrote vi on.
It had overloaded hjkl for the arrow keys compared to it's predecessors like the 7700A and successor 3A+ that had dedicated arrow keys.
The fact that Home/~ were the same key thus ~ being your home directory and that esc was where the tab key is on modern keyboards explains a lot about the vi keybindings.
Helix uses a selection-first action model: you select the word/paragraph/whatever you want to perform an action on, then you change/delete/whatever on that selection.
I think this is more intuitive than the "verb object" model Vim uses: if you get your selection wrong in Vim, you then need to undo the action and try again. In Helix, I can see what I am about to manipulate before I make the action.
I think at this point Vim wins out for being so ubiquitous, but I wish the Helix model took off first.
I think this is more intuitive than the "verb object" model Vim uses: if you get your selection wrong in Vim, you then need to undo the action and try again. In Helix, I can see what I am about to manipulate before I make the action.
I think at this point Vim wins out for being so ubiquitous, but I wish the Helix model took off first.
I've set up myself once to learn Helix. First there was Kakoune that sounded exciting with its new modal model, but what had me wanting to really give Helix a go, beyond being exciting, was that it advertised itself "batteries included". It promised to deliver all the cool things programmers' editors do recently.
But then I stopped abruptly when realized Helix misses a key feature of Vim: swap files. I can just start editing and have not have to worry about losing my work, may whichever of computer panic, computer running off charge, environment (desktop env or tmux) crash, etc. occur.
So edit semantics is cool, but fundamentals like recovery should be got right before being a serious contender.
(I did a quick search to see if there is any news on this front, but what I found is all about "recovery hooks for panic", which is far more less than what's needed - it's about an emergency saving of the work if something goes awry with the editor. I need to be protected from loss if something goes awry with the environment too...)
But then I stopped abruptly when realized Helix misses a key feature of Vim: swap files. I can just start editing and have not have to worry about losing my work, may whichever of computer panic, computer running off charge, environment (desktop env or tmux) crash, etc. occur.
So edit semantics is cool, but fundamentals like recovery should be got right before being a serious contender.
(I did a quick search to see if there is any news on this front, but what I found is all about "recovery hooks for panic", which is far more less than what's needed - it's about an emergency saving of the work if something goes awry with the editor. I need to be protected from loss if something goes awry with the environment too...)
Does anyone else use swap files? Personally, I find them annoying. Saving every time I leave insert mode is my preferred alternative: `autocmd! InsertLeave * silent! update`
Perhaps helix has something similar?
Perhaps helix has something similar?
Interesting how every use case is different. I personally hate swap files (they pollute directories and cause annoying warnings when opening the same file two times).
I use both in vim - if the selection is tricky use v or V to define the selection first, but most of the time "verb object" makes sense to me since that's how english works (tho could see it being unintuitive for non-SVO languages). "delete the next word" or "change inside the parentheses" roll off the brain and into the keyboard
To achieve something similar in vim one could use visual selection first and then run the verb on it. Helps with spotting mistakes or just tweaking selections in general. It is a tad bit tedious but a small bonus is `gv` which invokes the previous visual selection at a later point. That said selecting first isn't perfect because large selections often move the viewport around especially on small screens and that's really annoying but ahh that's life, always with the compromises.
The lead of NeoVim indicated that it would be possible to make this "grammar" an option for users. He didn't seem like it was something that's high priority, but he definitely was open to PRs to implement it.
I remember thinking roughly the same thing when I was a regular vim user. This was a long time ago now, so I forget the details, but from memory I used to use visual mode quite a lot, meaning I'd get to use the motion commands to select the region of interest first and then choose the operation to perform on it.
The typical vim model is a bit weird, but once I got practised with it it was actually quite surprising how much complicated stuff I could do purely by sight. But while the muscle memory aspect got me further than I'd have expected, it did only get me so far. Selecting the region first always seemed like it'd be the better way in general, being no worse when your fingers can do it automatically, while being better in the case where you're having to think about what you're doing.
The typical vim model is a bit weird, but once I got practised with it it was actually quite surprising how much complicated stuff I could do purely by sight. But while the muscle memory aspect got me further than I'd have expected, it did only get me so far. Selecting the region first always seemed like it'd be the better way in general, being no worse when your fingers can do it automatically, while being better in the case where you're having to think about what you're doing.
Helix splits the "select" and "verb" portions into two separate actions, so you can't easily repeat the last whole action (which you can do in Vim by pressing the dot key).
Which one is more intuitive is probably subjective, but personally, I find "dip -> delete inside parenthesis" far more intuitive (and closer to my line of thinking) than "select inside parenthesis. delete selection".
Which one is more intuitive is probably subjective, but personally, I find "dip -> delete inside parenthesis" far more intuitive (and closer to my line of thinking) than "select inside parenthesis. delete selection".
The visual-first paradigm means you need to repeat selection, not action, then act on multiple visible selections
This strikes me as the difference between English and Esperanto.
You wouldn’t design English as the international language but that’s what it has evolved to be.
You can still learn Esperanto as a hobby but it’s not going to be as useful day to day as English.
You wouldn’t design English as the international language but that’s what it has evolved to be.
You can still learn Esperanto as a hobby but it’s not going to be as useful day to day as English.
That's what I really enjoy about helix (and kak) - a different approach to the modal editing paradigm.
I'm still stuck on neovim for now, but progressively I'll make my way to helix I think.
I'm still stuck on neovim for now, but progressively I'll make my way to helix I think.
Huh, you can do visual selections in vim as well, and manipulate what you selected.
No, you can't, vim visual mode always extends the selection, so moving by two words would select two, not the last one, but to see how it's different the best way is to just use the visual-first editor a little bit
yes it works the same but for example in vim you do 'delete-inner-word' rather than `inner-word-delete`. The selection first model allows you to see what you are going to affect before you perform some verb on it.
I once wanted to try that, but I'm familiar with vim enough that these kind of manipulation is done without even thinking about it. Only visual line mode proves useful when I need to yank/delete whole sections.
Vim is this editor that a senior backend engineer told me to go try for a week, when I was still relatively junior. Like really try to remember all the shortcuts, not some half-assed attempt then laugh about not being able to remember <esc>:wq. If I were able to demonstrate fluent Vim skills at the end of the week, he'd gift me his TKL mechanical keyboard with a Vim keycap on the escape button.
It's been 9 years since that challenge, and I'm still typing on the Filco keyboard. Good memories. Although I've since moved on to NeoVim for the LSPs. It's nice that I can freely edit files on any machine for something I picked up in a week.
It's been 9 years since that challenge, and I'm still typing on the Filco keyboard. Good memories. Although I've since moved on to NeoVim for the LSPs. It's nice that I can freely edit files on any machine for something I picked up in a week.
I think this is a classic example of Unix-induced tunnel vision.
Because Vi[m] is just one example of a keyboard-driven UI that has been adopted in other places, whereas in fact there's a more common one that's used by more people on more computers every day... but it's not widely known that it's a thing and it has a name.
It's IBM CUA.
https://en.wikipedia.org/wiki/IBM_Common_User_Access
It is what defines the keyboard interface of MS Windows, and tens of millions of skilled Windows users use parts of CUA every day, from Alt+F4 to close a window to Ctrl+S to save to Ctrl+F to find to F2 to edit.
For blind and visually impaired users it is the sole or primary UI for Windows.
It is also largely supported in multiple Linux and FOSS desktops, such as Xfce, Unity, LXDE, LXQt, MATE, and others.
Sadly, KDE does not implement much of it, and modern GNOME almost none of it.
But it's there and most Gtk desktop apps support some of it -- although Gtk4 is driving that out now.
CUA provides a whole set of consistent keyboard controls for DOS, Windows 3.x, 9x, NT, 2000-11, OS/2, and almost all the Linux desktops until GNOME 3 came along. It has editing keys but also far more.
A skilled person can drive all of a Windows computer, and all apps, as quickly as a skilled Vi[m] user can -- well, can edit text and nothing else.
Because Vi[m] is just one example of a keyboard-driven UI that has been adopted in other places, whereas in fact there's a more common one that's used by more people on more computers every day... but it's not widely known that it's a thing and it has a name.
It's IBM CUA.
https://en.wikipedia.org/wiki/IBM_Common_User_Access
It is what defines the keyboard interface of MS Windows, and tens of millions of skilled Windows users use parts of CUA every day, from Alt+F4 to close a window to Ctrl+S to save to Ctrl+F to find to F2 to edit.
For blind and visually impaired users it is the sole or primary UI for Windows.
It is also largely supported in multiple Linux and FOSS desktops, such as Xfce, Unity, LXDE, LXQt, MATE, and others.
Sadly, KDE does not implement much of it, and modern GNOME almost none of it.
But it's there and most Gtk desktop apps support some of it -- although Gtk4 is driving that out now.
CUA provides a whole set of consistent keyboard controls for DOS, Windows 3.x, 9x, NT, 2000-11, OS/2, and almost all the Linux desktops until GNOME 3 came along. It has editing keys but also far more.
A skilled person can drive all of a Windows computer, and all apps, as quickly as a skilled Vi[m] user can -- well, can edit text and nothing else.
> There's a Vim mode in every single mainstream code editor out there.
Is it really a vim-mode, or a vi-mode? I mean, most of those are already very limited, but does any of them actually support vim-specific evolutions/changes?
And isn't the real question here: where does generic modal editing end, and when does vi(m) starts to display its specific personality?
Is it really a vim-mode, or a vi-mode? I mean, most of those are already very limited, but does any of them actually support vim-specific evolutions/changes?
And isn't the real question here: where does generic modal editing end, and when does vi(m) starts to display its specific personality?
Vim is efficient, in that there is no need for one's hands to leave the keyboard.
Vim is succinct, in that what is needed often takes less commands than those less frequent.
Vim is pliable, in that can be made to do whatever you wish.
Vim is everything, vim is nothing.
Mastering vim is to find Zen made possible by an exponential command space.
Vim is succinct, in that what is needed often takes less commands than those less frequent.
Vim is pliable, in that can be made to do whatever you wish.
Vim is everything, vim is nothing.
Mastering vim is to find Zen made possible by an exponential command space.
I’ve yet to get sucked into Vim, though I’ve given it a shot on a few occasions. I just feel too much muscle memory with whatever you call normal editing. One of these days I want to really stick with it because I do love the verb/action/modifier idea. I’m even building a similar keyboard-driven editor for building UIs. It has commands like “s a i” (select all images), “a t n” (add text element as next sibling), etc.
> I just feel too much muscle memory with whatever you call normal editing.
You end up the same with Vim eventually. After almost 13 years of using it, I sometimes have to actually type the things I do to articulate what command it is. I also had a moment where someone said, “it’s just like the ‘p’ command in normal mode” and I had to really think about what they meant—in my head I’m just like “put line” and it just happens.
You end up the same with Vim eventually. After almost 13 years of using it, I sometimes have to actually type the things I do to articulate what command it is. I also had a moment where someone said, “it’s just like the ‘p’ command in normal mode” and I had to really think about what they meant—in my head I’m just like “put line” and it just happens.
Agree that Vim is a language to talk to your computer, but it's not necessarily efficient. Vim is famously an imperative editor: You have to tell Vim the sequence of steps to perform. Clicking your mouse on a position on the screen is declarative: You declare you want the cursor here. With Vim you have to imperatively walk the cursor to where you want to go, or god forbid use something like easymotion.
Setting aside that you can enable mouse mode in vim and use the mouse to your heart's desire --
and setting aside the "declarative" vs "imperative" nomenclature debate --
vim is pretty dang efficient. Typing `gg` to go to the beginning of a file, or `G` to go the end. Or all the other variety of motions. There are a lot.
Also, there is not necessarily any need to move the cursor anywhere. For example, if I'm in the middle of writing some string and I've decided to change the whole thing, `<ESC>ci"` does that, with no cursor movement required.
and setting aside the "declarative" vs "imperative" nomenclature debate --
vim is pretty dang efficient. Typing `gg` to go to the beginning of a file, or `G` to go the end. Or all the other variety of motions. There are a lot.
Also, there is not necessarily any need to move the cursor anywhere. For example, if I'm in the middle of writing some string and I've decided to change the whole thing, `<ESC>ci"` does that, with no cursor movement required.
You can, in fact, click to set the cursor position and even click and drag to select.
It is imperative in certain editors that you fumble for the mouse whilst in vi one can simply declare 3ff to get to the third f on the line. Granted, I mostly do not use certain editors, and accidentally compiled mouse click support out of the terminal—brushing the trackpad risked spamming programs with mouse noise, and some programs would sometimes do silly things with it. The mouse is fine for focusing terminals, I guess. (No, not vim, vi.)
> With Vim you have to imperatively walk the cursor to where you want to go, or god forbid use something like easymotion.
If you prefer to use a mouse you can do that in Vim too.
It even works over SSH.
If you prefer to use a mouse you can do that in Vim too.
It even works over SSH.
> With Vim you have to imperatively walk the cursor to where you want to go
I used to use vscode with mouse. Then vscode + vim with mouse. Then I forced myself to actually learn how to "properly" use vim, including all the motions plus enabling smart line numbers.
As a result, my right hand switches between keyboard and mouse much less than they used to, and I can do development work with my hands stay on the keyboard for minutes or longer. It made me more efficient, and RSI was much less of a problem.
I used to use vscode with mouse. Then vscode + vim with mouse. Then I forced myself to actually learn how to "properly" use vim, including all the motions plus enabling smart line numbers.
As a result, my right hand switches between keyboard and mouse much less than they used to, and I can do development work with my hands stay on the keyboard for minutes or longer. It made me more efficient, and RSI was much less of a problem.
set incsearch
Now use / (+ n or N) + Enter to move around
Done
Now use / (+ n or N) + Enter to move around
Done
Incremental search in vim is great, you can also cycle through results with CTRL-G/T while typing.
This even works as a motion (e.g. d / foo, then ctrl G until you hit the right foo, then enter to delete until there).
This even works as a motion (e.g. d / foo, then ctrl G until you hit the right foo, then enter to delete until there).
That is great! Thanks
That's like telling some small child they are lesser because they can't walk because they're still learning to crawl. The systems that vim worked on didn't even know what a mouse was.
imagine you would remove the functionality that Vim mode in VSCode
gives you from Neovim.
imagine you what?
imagine you what?
I think the author is not a native-English speaker.
They mean
> imagine if you remove the functionality that Vim mode in VSCode gives you from Neovim.
They mean
> imagine if you remove the functionality that Vim mode in VSCode gives you from Neovim.
It still doesnt make sense. If you remove vim mode from neovim you have... Nothing?
Even though I wince at mis remembered muscle memory using it, I still wish nvi had progressed a little further. I mostly turn off vim features. Default cut-paste with code indent is a giant mismatch. It's cruder, and itself a mishmash of non-joy code, but I found nvi suited me well for decades on netbsd and freebsd, and I use it still. I do run the port on osx but somehow each upgrade I find myself slipped back into vim. And on debian and the like.
I live in Emacs for org, and vi for code edit. Happy mix these last 40+ years.
Sometimes it's hard to recall that ex exists, inside vi. But if you do any :command that's where you are. Inside a simpler editor landscape embedded in the visual world.
Ed is a sometimes tool. Always gratifying to use it!
I live in Emacs for org, and vi for code edit. Happy mix these last 40+ years.
Sometimes it's hard to recall that ex exists, inside vi. But if you do any :command that's where you are. Inside a simpler editor landscape embedded in the visual world.
Ed is a sometimes tool. Always gratifying to use it!
Learning vim was one of the best things I did for myself at work. Completely changed everything about the way I work and made me so much faster.
I love this take. I was a die-hard Vim/Neovim zealot... but these days I absolutely love the ecosystem of tools that support normal mode. For so long hand-cramping emacs keybindings were sort-of-standard-in-a-few-places.
If you're not convinced vimming is the best way to interact with your editor, you probably haven't seen a really proficient vimmer.
If you're not convinced vimming is the best way to interact with your editor, you probably haven't seen a really proficient vimmer.
And meanwhile in every thread or article about vim, it is very rare to mention remapping Caps Lock to Escape (or the other lesser IMHO lesser options ) even though one third of user do it.
The other two third are deluded tool fetishists that are ready to suffer that their most important key is the furthest away from the home of row because "you get used to it" even if that's just an unfortunate historical accident. I would have not stuck to vim at all if not for this one trick and I suspect that's the main reason behind many dropouts
LOL this made me chuckle. :)
I always remap caps to ctrl because ctrl-[ is an acceptable escape key for me as I like to use other insert mode shortcuts. Eg ctrl-h, ctrl-m, ctrl-k etc.
I know some people map to escape/ctrl when held but that usually means installing something like Karabiner.
I always remap caps to ctrl because ctrl-[ is an acceptable escape key for me as I like to use other insert mode shortcuts. Eg ctrl-h, ctrl-m, ctrl-k etc.
I know some people map to escape/ctrl when held but that usually means installing something like Karabiner.
Well then you should mention it when talking about vim to non-vimmers as not to leave them in the dark with the defaults.
The question is not what solution you found to avoid the Escape key but that you did.
And even though you are probably used to your solution having the most important key in your program be a weird combo is not great imho. And you are missing out on bash/zsh/gdb and other command line vim modes.
And even though you are probably used to your solution having the most important key in your program be a weird combo is not great imho. And you are missing out on bash/zsh/gdb and other command line vim modes.
> it is very rare to mention remapping Caps Lock to Escape
I change mine to Ctrl. This way escape for me is Ctrl + [. Ctrl is too useful to be in an awkward position.
I change mine to Ctrl. This way escape for me is Ctrl + [. Ctrl is too useful to be in an awkward position.
I have mapped Caps Lock to both Ctrl and Escape simultaneously. If you just tap it it's Escape and if you hold it down it's Ctrl, and it's easy to accomplish with xcape.
I actually usually hit my Ctrl with the base of the pinky (ie: pad/palm of the hand) in a lot of cases.
Pinky sideways is an akward position, Ctrl would be better remapped to a thumb-accessible key
I recently gave up on VSCode because the Vim mode is still substandard, missing keybindings, and constantly glitches out in new and fun (read: not-fun) ways. I’m just gonna use NeoVim and program the IDE myself, in a true moment of going super-saiyan as a programmer
How do you explain "w" and "wq" to save and quit the editor with "verb adjective object" model?
These two and "i" is all I remember about vi. Or is vi a different thing from vim and this model doesn't apply?
These two and "i" is all I remember about vi. Or is vi a different thing from vim and this model doesn't apply?
"w" and "wq" happen in command mode. "verb adjective object" happens in normal mode. Command mode is more like ed.
vim is vi "IMproved." Just a more featureful version.
vim is vi "IMproved." Just a more featureful version.
I don't understand why people keep talking about :wq when :x has been a thing for so long now
I dont understand why people even do that when ZZ is easier xD
I disagree that's two combos (Shift + z) on awkward key whereas you should be used to : by now
ZZ is less key presses - :wq is [shift;wq], the keys of which are spread all over the keyboard vs [shiftzz] which is much less traversing, quicker and can be done with little and ring finger with no physical trouble
to add, :x is still [shift;xENTER] so 4 key presses also!
This is probably because :X encrypts a file so too easy to make that mistake?
Is anyone here using Lazyvim? I switched to this from VS code and it feels much more productive and lightweight on my computer.
I never got into VIM before until I saw some Youtube personality using Lazyvim.
I never got into VIM before until I saw some Youtube personality using Lazyvim.
To me there was a distinct "aha" moment when the "vim language" suddenly made sense. Makes me think of when kids suddenly discover how to read.
I was in a PyCon presentation about the Python bytecode when I came up with the idea that vim editing commands are a bytecode for executing text manipulation.
I've been using vscode in java because of the cumbersome file navigation in bash. Is there easy full tree navigation in vim?
It may also be because the terminal view is much smaller than vscode's smaller navigation font so I can see much less of the file tree in a terminal program such as ranger.
I also never really mastered windows although I did master vim buffers.
I do use tmux.
It may also be because the terminal view is much smaller than vscode's smaller navigation font so I can see much less of the file tree in a terminal program such as ranger.
I also never really mastered windows although I did master vim buffers.
I do use tmux.
In my workflow I've integrated both ranger file manager and fzf as file pickers: fzf when I'm inside a git repo ('git ls-files | fzf' - but doesn't have to be this way), and ranger for elsewhere. Both ranger and fzf are amenable to being used for this purpose, so all it takes is a couple of lines of hand-rolled vimscript - no need to wait for a third party integration plugin to drop.
What's a rough sketch of your idea for the vimscript?
> There's a Vim mode in every single mainstream code editor out there
Not Jupyter notebooks though (by default)
Not Jupyter notebooks though (by default)
My ode to why speed even matters https://h.43z.one/vimsteps/0
>"Wha Is Vim"
Something I've never learned. Not proud of it but I do not think I am missing anything either. I write native software for Linux for living at the moment.
Something I've never learned. Not proud of it but I do not think I am missing anything either. I write native software for Linux for living at the moment.
> I do not think I am missing anything either
How could you possibility know that unless you're familiar with Vim?
How could you possibility know that unless you're familiar with Vim?
I played with it and do not think I need it.
I don’t think there’s any reason why you have to learn Vi/Vim. I think someone could go their whole career without that. That seems like a perfectly legitimate choice to me.
…but, I learned vi somewhere between less running on MSDOS and an embedded programming course at uni in the 90s.
I’ve used the those shortcuts in database clients, shells and web browsers, etc. ever since.
That’s a long time and a lot of value. It’s payed off so much that I don’t really remember if it was difficult to learn; I just use the keyboard and get the edits I want without much thought.
Being able to know something like that and bring it with you across operating systems has been useful.
I’m pretty sure it will still be useful in twenty years time.
…but, I learned vi somewhere between less running on MSDOS and an embedded programming course at uni in the 90s.
I’ve used the those shortcuts in database clients, shells and web browsers, etc. ever since.
That’s a long time and a lot of value. It’s payed off so much that I don’t really remember if it was difficult to learn; I just use the keyboard and get the edits I want without much thought.
Being able to know something like that and bring it with you across operating systems has been useful.
I’m pretty sure it will still be useful in twenty years time.
>"Being able to know something like that and bring it with you across operating systems has been useful."
I did not say it is not useful for people who use it. I imagine for them it gets the job done perfectly. We do not have to be all the same.
I did not say it is not useful for people who use it. I imagine for them it gets the job done perfectly. We do not have to be all the same.
Sorry I hope it came across in my message but I totally agree with you.
We most definitely do not need to all use the same tools for the job. Vive la différence.
We most definitely do not need to all use the same tools for the job. Vive la différence.
No time like the present. Give it a try. Even if you just use it for editing /etc files it’s much more efficient than nano.
Don’t be intimidated by the huge feature set. I’ve been using it practically daily for 25 years and I still only use a small fraction of the available commands.
Don’t be intimidated by the huge feature set. I’ve been using it practically daily for 25 years and I still only use a small fraction of the available commands.
>"Give it a try"
I have. Not my cup of tea. Small file I edit in nano / whatever else. Anything serious is remote editing using some IDE. The terminal I use also has SSH file browser where you can click on file and edit it locally using any editor. It will be saved back to where it came from.
I have. Not my cup of tea. Small file I edit in nano / whatever else. Anything serious is remote editing using some IDE. The terminal I use also has SSH file browser where you can click on file and edit it locally using any editor. It will be saved back to where it came from.
I am too stupid for Vim. The bottleneck is my brain, not my typing speed.
Here is some material to challenge that idea:
https://danluu.com/productivity-velocity/
Is also funny to phrase it in terms of bottlenecks because bottleneck optimization is an 80/20 approach to performance. People who are serious about perf don’t practice it.
80/20 is good for once a month tasks. When it comes to the primary work I do everyday I don’t want to leave 20% on the table.
https://danluu.com/productivity-velocity/
Is also funny to phrase it in terms of bottlenecks because bottleneck optimization is an 80/20 approach to performance. People who are serious about perf don’t practice it.
80/20 is good for once a month tasks. When it comes to the primary work I do everyday I don’t want to leave 20% on the table.
I spend maybe 90-95% of my time thinking, looking up existing code, reading documentation, solutions, and code exemplars online, and trying to engineer a solution either in my head or on paper. I spend at most 10% actually typing. It's just not something that I've really ever felt has slowed me down.
Did you look at the article?
I did. I disagree with the premises, the (rather exaggerated) examples given, and furthermore the author's situation appears very different compared to mine. I am a very junior developer. The codebase I work on is established and if I ever make edits, it's confined to a handful of lines. It takes a long time for me to understand and parse an existing code base. I am unlikely to ever do the sort of text-slinging that Vim users tend to demonstrate on YouTube. I move between work and home, and I type on different keyboards with different physical layouts.
At the end of work I am so physically and mentally exhausted that I couldn't give two hoots whether I used Vim, VS Code, or the trendy modal AI-augmented editor written in Rust. I just want to get dinner, flop onto my bed, text some friends and get sleep. I have a couple of blog-posts that I've been sitting on for months because I haven't had the time nor energy to sit and write them, even at weekends.
Given all this, learning to use Vim is just another drag. Oh, and I should mention—I am exceptionally lazy. I'm not the so-called 'smart lazy' type of person. I'm lazier than that. I simply don't do stuff if I can afford not to.
The author suggests I now profile my own typing to speed it up? I frankly couldn't be bothered. I type reasonably fast anyway and Vim isn't going to speed things up at all.
At the end of work I am so physically and mentally exhausted that I couldn't give two hoots whether I used Vim, VS Code, or the trendy modal AI-augmented editor written in Rust. I just want to get dinner, flop onto my bed, text some friends and get sleep. I have a couple of blog-posts that I've been sitting on for months because I haven't had the time nor energy to sit and write them, even at weekends.
Given all this, learning to use Vim is just another drag. Oh, and I should mention—I am exceptionally lazy. I'm not the so-called 'smart lazy' type of person. I'm lazier than that. I simply don't do stuff if I can afford not to.
The author suggests I now profile my own typing to speed it up? I frankly couldn't be bothered. I type reasonably fast anyway and Vim isn't going to speed things up at all.
> I just want to get dinner, flop onto my bed, text some friends and get sleep.
Sorry, I was using the assumption you were looking to improve your craft and make great contributions.
Sorry, I was using the assumption you were looking to improve your craft and make great contributions.
Could your horse be any higher?
If you’re happy with where you are at why would you want to learn something new like vim?
As a modern day tech person, you only spend 4 hours a week on your keyboard across browsers, email, messaging, command line, etc? What about your personal life?
Even then, learning Vim could improve your computer interactions easily by 10%. That's 40 min a week or ~34 hours in a year.
https://xkcd.com/1205/
Even then, learning Vim could improve your computer interactions easily by 10%. That's 40 min a week or ~34 hours in a year.
https://xkcd.com/1205/
I mean during my work hours I spend the majority of my time reading and thinking rather than programming.
In my personal life I try not to program. I do other things.
In my personal life I try not to program. I do other things.
vi is fine. never seen the need to get all fancy with vim.
vim is an operating system that allows also editing files
Isn't this an emacs joke? Hearing this for the first time for vim.
Cho 55
Yet another article about vim that does not mention remapping Escape even though it's a dumb historical accident that the most important key is the furthest away from the home row.
adamnemecek(3)
And they’re always frustratingly incomplete and/or buggy. Some motions will be unimplemented, or will behave incorrectly, especially with regards to boundaries around whitespace inclusion or exclusion in a motion. Things you added to Vim and got used to are unavailable, and so your ysa") to put parentheses around the string your cursor is on just doesn’t work. (Lack of vim-surround definitely gets me frequently.)
In VS Code, it maintains its own undo stack, and the interactions between the two undo stacks are terrible and terribly frustrating—yet doing without might be even worse, because they behave very differently.
And too often in a browser context, ^W will close your tab, losing data, rather then being inhibited and erasing the last word, as it should. That one is practically unforgivable in a Vim mode, yet common. That, more than anything else, will make me avoid a Vim mode.