> There's a Vim mode in every single mainstream code editor out there.
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.
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 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.
Doing a quick search in the repo i see multiple issues where people report using vscodium but none of them seem to report any immediate breakage. If you're experiencing a problem with it, it is only in vscodium?
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...
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.
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.
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.
> 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.
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.
"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!
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.
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.
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.
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.
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.
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.
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
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).
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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'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...)
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`
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.
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".
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.
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 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?
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.
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.
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
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.
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.
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 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.
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
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.
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 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
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
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
I personally am not a vim user in any way and have no intention to use it, neovim, or its keybindings, but I thoroughly enjoy such articles.
According to the Lindy Effect, we can expect such articles to continue until 2060. I personally feel that vim and it's derivatives will be with us as long as our civilization supports computing.
Would you say that software, in general, is improving in the year of our lord 2024? We may have taken a wrong turn somewhere. Going back may be the answer.
Vim stands for "Vi IMproved" so it literally is meant to be an improvement, and IMO it really is although plain old Vi is still better than most editors.
Every time I try to use vscode I start losing time because within a few months I become involved in some kind of diplomacy between the maintainers of vscode and some adjacent component over a bug that neither wants to own.
Stuff just works in vim. So uh yeah, definitely an improvement. And re: may god have mercy on us all... Yeah it's not looking good. I'd really like it if we could get our shit together, but ever since we put the marketing people in charge the engineering has been looking increasingly flimsy.
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.