" I mean, I knew about R but I thought that, surely, no one really ever uses it."
How could someone use vim without using R? I literally use that every single time I use vim (multiple times per day) and have done for 20+ years at this point. Do people only use "change inside" and cw and things like that? I mean sure I use them but not to ever use replace is really weird to me.
Hmm I used Vim for about 10 years and I never used R. I preferred one of the c- variants, usually ct and cas. I guess it depends on acquired muscle memory?
What is a typical R use case for you? R doesn't feel worth it to me. If I'm changing a word, cw is almost always better, unless maybe the new word has the exact same number of chars as the old word.
That requires pressing <Esc> or whatever to leave insert mode first. I'll do it if I need to do some nontrivial motions first (because i_^O is just awkward outside of mappings), but otherwise no.
I would just cw and space it back to correct alignment. I too edit ascii table by hand, and quite often and just find R not very useful in even this case.
In the original vi, if you use cw to change it into a longer word, you can't just use <DEL> to remove spaces after the word, but have to use <ESC> and x. So R is often more practical, and it got into my muscle memory before vim existed.
Yeah exactly. So if I'm editing text that is somehow quasi fixed width like a table cell but doesn't fit the classic vim definition of a word or a neatly delimited thing that I can use ci/ca with.
So for example this morning I was editing cells in a latex array. They are delimited by "&" and each one is some sort of equation that doesn't fit a normal vim word definition. R to the rescue. If I need more characters than are there in the cell then I go <esc>I to carry on but this morning, R was perfect.
I never toggle insert mode with an ins key because I got in the habit of using minimalist keyboards with weird custom mappings that didn't have that key (or not that readily available) often.
I'm usually faster at retyping a word that has a typo, than moving to the exact locations that need edits within a word. So the c-varianta are better for me.
Also, I find it's usually just easier for my brain to just retype a word from the start, rather than edit and fix the typo. And R is annoying if the length doesn't match.
A lot of my Vim usage is optimized to reduce the amount of time I need to spend thinking about what to do, rather than minimizing the number of keystrokes or whatnot.
Same, there are so many ways to do the same thing.
I'd have used R had I learned about it sooner but sed-like command for search and replace really makes it obsolete for me.
I personnally find it weird that parent can't fathom that some people are doing otherwise.
C (until end of line) or cw, ce or similar can be quicker sometimes than thinking exactly where the char is, or an alternative that fits your brain better.
One time, I paired with a guy that used `R` all the time.
It was an eye-opener for me, too. I use `R` a little more often ever since then, but -- like a lot of others here -- my mental model defaulted to more of a `cw` approach.
Maybe there's just two types of vim users. This could be the latest new Silicon Valley personality test.
I'd just like to point out to the vim curios Emacs users lurking in here (hi guys, you will succumb eventually) that he doesn't mean the R programming language.
Definitely nobody uses that, true. And we aren't going to make you when you decide to switch over, it isn't like a prerequisite to use the editor.
Nor is some weird shitty lisp from the 80s. There was an abomination called Vimscript until Neovim decided to murder it. Praise be.
It is now scriptable with Lua, Python, Ruby, JS if you're a satanist (who am I kidding, you probably are), whatever you want.
So honestly you're running out of excuses at this point. ;)
P.S. - Since a vim-mode will always only support the subset of Vim the authors care about it is rather pointless. Also, Neovim has a robust ecosystem of plugins this Zed thing is leaving behind. There is no escape no matter how hard novelty editors will try to fix what isn't broken.
I have a repeating memory of using R in C-v context, but can’t think of an example. Vim is really reflective. I suspect r doesn’t work in block visuals, which I use often. Need to test.
Nonetheless, normal R is a useful function for editing tables and other ascii art-y texts. How can you not need it?
For non-vimers who haven’t read tfa: R turns on overwrite mode akin to pressing Ins in command line. r uses temporary replace mode for a single character. Rtext<Esc> replaces four chars, rt replaces current char to t. In both cases we start and end in normal mode.
My brain is slower than my fingers so my edits are never that surgical. If I goofed a few letters in a word I just ciw and retype the whole thing. I never use insert mode when bot using vim either. My fingers just aren't capable of typing individual letters at any useful speed. They always want to type whole words.
Been awhile since I’ve accidentally pressed r during visual-block editing but vim will gladly replace every cell under your selection with whatever character you choose after hitting r
Whoops, I've used vim on and off for a long time and did not know about R. I usually either did cw, or ci, or switched to visual mode, jumped to wherever, c, then enter new stuff.
I have used VIM for a very long time and I didn’t even know R was a thing.
Now that I do know what it is I’m still not sure why I’d use it.
The reality is that VIM allows you to do the same thing in many different ways and people tend to pick a style and rarely use anything outside that style.
So, for me, ciw, cw, ct<char>, cf<char>, ci<text object>, c$ are pretty much all the editing commands I use. I’m partial to ‘c’ for my editing needs.
Is there a guide or spec to how Vim defines text/a word?
I'm thinking of cursor motions like 'e' or 'w'. If you paste in a URL put your cursor on the starting 'h' and press 'e', your cursor will move to the : in the URL.
That's different from how operating systems navigate text on ctrl-right so I'm wondering if Vim modes/clones have a spec or definition, or if they copy through observation.
Different file types can have different values for this. For example in clojure / and : are commonly used, so they are added to `iskeyword`. In .clj files "w" navigates across `:person/first-name` as one word.
Also FYI if you didn't know and are having that problem with URLs, capital E and W navigate across vim WORDS, which is defined as all non-whitespace characters.
I might be totally wrong, but it feels like reimplementing all of vim is not easier that mapping neovim stuff to zed stuff. The author says they would lose it if they embed neovim, but I'm not yet convinced.
I have been a vi/vim/neovim user for decades, and I actually use vscode more because of an excellent neovim plugin that does exactly what the author is eschewing: embedding neovim itself.
I have seen so many attempts at trying to include vi keybindings. Mostly, they fall short enough that the attempts are almost worthless. You have to get it mostly right or it fails to satisfy the very people you are trying to lure.
You can't map neovim stuff to zed stuff if the foundations ("the data structures to represent text, the CRDTs, the render pipeline, the custom Async Rust runtime" FTA) are different.
Zed's vim plugin is not all there. I just ran into an example case.
This text - 'asdf-asdf'. If you put the cursor on the hyphen and in Normal mode press dw - in Zed this deletes all the way to the ' and in neovim it only deletes the hyphen, I guess it counts as its own word. Subtle differences like these throw off your muscle memory.
I wonder if we have numbers of Neovim adoption in its stated goal of being embedded. From what I've seen, adoption for this goal is SUPER low.
Sure, there are tons of projects that seem to do something in this area. But most of them seem immature, "a single dev worked on them for a bunch of months as a hobby project and then abandoned them" kind of thing.
For example I don't think anyone's making any kind of commercial IDE embedding Neovim. Or at least some type of lifestyle business like Sublime Text.
The type of thing where people "put their money where their mouth is".
I use it everyday as part of my setup, and I've been very pleased with it. It can utilize keybinds, settings, and even entire extensions from Neovim. I even use the same init.lua settings file as my actual Neovim install, by checking for an environment variable that only VSCode sets to not load extensions/bindings that don't apply to VSCode.
For example, I have ']c' bound to jump to the next changed hunk in a file. This works by leveraging a git plugin in Neovim proper, but since VSCode has built-in git support, it instead invokes a VSCode command. Even more complex extensions like Hop/Easymotion work great. I've had much better experience with it than the other Vim binding extension, which just recreates the Vim experience with native VSCode features.
I'm also using the NeoVim plugin right now. Before that I was using the other popular one (can't remember the name, VSVim or something), but the latest version gave issues so I switched.
Only thing that's not working for me is when CodePilot changes some code, I can't edit any more text in that tab. Close and reopen works again.
I guess it will always have peculiarities, but it's still better than anything else in my opinion.
I've tried this before out of curiosity, it's usually because I CBA to deal with a vim config or managing & maintaining the integration. For vim mode I just use the standard "vim" extension and sync my settings to all my machines without thinking about it. The VS marketplace says this approach has about 6.5M installs.
> The VS marketplace says this approach has about 6.5M installs
And it's entirely to do with the fact that the creators were the only ones shameless enough to call their extension "Vim".
In the early days of VS Code, there were a few extensions that tried to tackle the problem of bringing Vim-style key bindings to VS Code. The VSCodeVim project, branded as simply "Vim" in the extension store, was easily among the worst of them at the time. With the unearned advantage from squatting on the "Vim" name, however, it managed to get most of the attention and contributions.
I want to see VS Code have first hand support from Microsoft as well as Visual Studio itself, and JetBrains needs official support. Once that happens anyone trying to compete with these major IDEs will kind of be forced to do so.
.Vi. are the Unix CLI companion, when a CLI UI it's not enough Unix have offered a 2D UI to do more, a bit violating Unix principles but still relatively integrated in Unix ecosystem/IPCs/model.
Embedding, meaning copying the UI, something like evil in Emacs, it's a bit a nonsense because the strongest point of .Vi. is the Unix model witch is not a 2D DocUI model. Yes modal editing is powerful and yes in both ".Vi. alike editing vs Emacs editing" you can get powerful performances superior to any other "text editor" we have ever seen so far BUT that's not the point, the point is the role of the editor inside a broad system.
Emacs is an ecosystem, incomplete since it lacks a proper LispM underneath, but closely similar to classic Smalltalk workstations, a single tool that do anything inside the tool itself, user programmable and fully exposed to the human user. .Vi. on contrary shine in a CLI unix environment. Both fall short outside their own ecosystem: Emacs fall short when you have to be outside Emacs, .Vi. when you are outside of Unix model.
The point is that a powerful desktop is a single-application, user-programmable live framework like original desktops, modern systems are designed for commercial purposes as a kind of Babel's tower of insulated stuff anyone self-contained and badly fit together in an "OS+.*". You can't escape this trap. Or the entire system works integrated or you just add a bit of sugar witch might or might be not helpful but it will fall short anyway.
This app is absolute garbage. Why would I replace nvim with a poor man's IDE that has buttons for github copilot and requires me to sign in for collab? JFC is this what people expect from a code editor these days? Maybe just open notepad or gedit and write code instead of playing around with AI. Pass, will never try this app again.
Back when I was building an IDE with a custom text editor, I initially used embedded Neovim thinking I would get the entire vim feature set out of the box for free. Unfortunately this became a never ending source of bugs. I think the fundamental problem was that my application was structured like a game with a main loop in a single thread, and Neovim turned text editing into an async operation, where I would have a separate thread reading events from Neovim and then trying to safely update the global buffer.
Also, I was constantly fighting/reverse engineering Neovim to get the granular level of control over behavior that I needed for a seamless integration. It’s just a type of programming that’s extremely frustrating and not fun.
In the end I implemented custom vim emulation from scratch and surprisingly it wasn’t that hard to get the “20% of features that people actually use 80% of the time,” except it’s more like 5% and 95%, and in exchange I could own the whole stack instead of depending on a third party black box. Never been happier to delete a whole subsystem of code in my life.
59 comments
[ 5.4 ms ] story [ 115 ms ] thread" I mean, I knew about R but I thought that, surely, no one really ever uses it."
How could someone use vim without using R? I literally use that every single time I use vim (multiple times per day) and have done for 20+ years at this point. Do people only use "change inside" and cw and things like that? I mean sure I use them but not to ever use replace is really weird to me.
It's faster than `ct<somechar>` for replacing part of a word.
Using `<Insert>` to toggle the mode is also something I do fairly regularly ...
I'm past the point of consciously doing these things so I probably use it more than this.
So for example this morning I was editing cells in a latex array. They are delimited by "&" and each one is some sort of equation that doesn't fit a normal vim word definition. R to the rescue. If I need more characters than are there in the cell then I go <esc>I to carry on but this morning, R was perfect.
I never toggle insert mode with an ins key because I got in the habit of using minimalist keyboards with weird custom mappings that didn't have that key (or not that readily available) often.
A lot of my Vim usage is optimized to reduce the amount of time I need to spend thinking about what to do, rather than minimizing the number of keystrokes or whatnot.
I personnally find it weird that parent can't fathom that some people are doing otherwise.
It was an eye-opener for me, too. I use `R` a little more often ever since then, but -- like a lot of others here -- my mental model defaulted to more of a `cw` approach.
Maybe there's just two types of vim users. This could be the latest new Silicon Valley personality test.
I press I, I add my commit message, then I press :wq and I'm done.
Definitely nobody uses that, true. And we aren't going to make you when you decide to switch over, it isn't like a prerequisite to use the editor.
Nor is some weird shitty lisp from the 80s. There was an abomination called Vimscript until Neovim decided to murder it. Praise be.
It is now scriptable with Lua, Python, Ruby, JS if you're a satanist (who am I kidding, you probably are), whatever you want.
So honestly you're running out of excuses at this point. ;)
P.S. - Since a vim-mode will always only support the subset of Vim the authors care about it is rather pointless. Also, Neovim has a robust ecosystem of plugins this Zed thing is leaving behind. There is no escape no matter how hard novelty editors will try to fix what isn't broken.
There can be only one! /Sean Connery accent
Nonetheless, normal R is a useful function for editing tables and other ascii art-y texts. How can you not need it?
For non-vimers who haven’t read tfa: R turns on overwrite mode akin to pressing Ins in command line. r uses temporary replace mode for a single character. Rtext<Esc> replaces four chars, rt replaces current char to t. In both cases we start and end in normal mode.
Now that I do know what it is I’m still not sure why I’d use it.
The reality is that VIM allows you to do the same thing in many different ways and people tend to pick a style and rarely use anything outside that style.
So, for me, ciw, cw, ct<char>, cf<char>, ci<text object>, c$ are pretty much all the editing commands I use. I’m partial to ‘c’ for my editing needs.
I'm thinking of cursor motions like 'e' or 'w'. If you paste in a URL put your cursor on the starting 'h' and press 'e', your cursor will move to the : in the URL.
That's different from how operating systems navigate text on ctrl-right so I'm wondering if Vim modes/clones have a spec or definition, or if they copy through observation.
Different file types can have different values for this. For example in clojure / and : are commonly used, so they are added to `iskeyword`. In .clj files "w" navigates across `:person/first-name` as one word.
Also FYI if you didn't know and are having that problem with URLs, capital E and W navigate across vim WORDS, which is defined as all non-whitespace characters.
If they add more features, though, they'd have to make sure that they work with nvim. As the amount of features grows, that would become harder.
I would definitely prefer embedded neovim, but I can definitely see why they'd do it this way.
Does the zed editor not have plugins?
I have been a vi/vim/neovim user for decades, and I actually use vscode more because of an excellent neovim plugin that does exactly what the author is eschewing: embedding neovim itself.
I have seen so many attempts at trying to include vi keybindings. Mostly, they fall short enough that the attempts are almost worthless. You have to get it mostly right or it fails to satisfy the very people you are trying to lure.
This text - 'asdf-asdf'. If you put the cursor on the hyphen and in Normal mode press dw - in Zed this deletes all the way to the ' and in neovim it only deletes the hyphen, I guess it counts as its own word. Subtle differences like these throw off your muscle memory.
Zed sees that whole string as one word object..
Sure, there are tons of projects that seem to do something in this area. But most of them seem immature, "a single dev worked on them for a bunch of months as a hobby project and then abandoned them" kind of thing.
For example I don't think anyone's making any kind of commercial IDE embedding Neovim. Or at least some type of lifestyle business like Sublime Text.
The type of thing where people "put their money where their mouth is".
For example, I have ']c' bound to jump to the next changed hunk in a file. This works by leveraging a git plugin in Neovim proper, but since VSCode has built-in git support, it instead invokes a VSCode command. Even more complex extensions like Hop/Easymotion work great. I've had much better experience with it than the other Vim binding extension, which just recreates the Vim experience with native VSCode features.
Only thing that's not working for me is when CodePilot changes some code, I can't edit any more text in that tab. Close and reopen works again.
I guess it will always have peculiarities, but it's still better than anything else in my opinion.
https://marketplace.visualstudio.com/items?itemName=vscodevi...
https://github.com/VSCodeVim/Vim
And it's entirely to do with the fact that the creators were the only ones shameless enough to call their extension "Vim".
In the early days of VS Code, there were a few extensions that tried to tackle the problem of bringing Vim-style key bindings to VS Code. The VSCodeVim project, branded as simply "Vim" in the extension store, was easily among the worst of them at the time. With the unearned advantage from squatting on the "Vim" name, however, it managed to get most of the attention and contributions.
Are any of the others still in development? Any of them still worth picking over VSCodeVim?
Embedding, meaning copying the UI, something like evil in Emacs, it's a bit a nonsense because the strongest point of .Vi. is the Unix model witch is not a 2D DocUI model. Yes modal editing is powerful and yes in both ".Vi. alike editing vs Emacs editing" you can get powerful performances superior to any other "text editor" we have ever seen so far BUT that's not the point, the point is the role of the editor inside a broad system.
Emacs is an ecosystem, incomplete since it lacks a proper LispM underneath, but closely similar to classic Smalltalk workstations, a single tool that do anything inside the tool itself, user programmable and fully exposed to the human user. .Vi. on contrary shine in a CLI unix environment. Both fall short outside their own ecosystem: Emacs fall short when you have to be outside Emacs, .Vi. when you are outside of Unix model.
The point is that a powerful desktop is a single-application, user-programmable live framework like original desktops, modern systems are designed for commercial purposes as a kind of Babel's tower of insulated stuff anyone self-contained and badly fit together in an "OS+.*". You can't escape this trap. Or the entire system works integrated or you just add a bit of sugar witch might or might be not helpful but it will fall short anyway.
Also, I was constantly fighting/reverse engineering Neovim to get the granular level of control over behavior that I needed for a seamless integration. It’s just a type of programming that’s extremely frustrating and not fun.
In the end I implemented custom vim emulation from scratch and surprisingly it wasn’t that hard to get the “20% of features that people actually use 80% of the time,” except it’s more like 5% and 95%, and in exchange I could own the whole stack instead of depending on a third party black box. Never been happier to delete a whole subsystem of code in my life.
https://zed.dev/docs/vim#custom-key-bindings
So it's by default qwerty-centric.