top | item 40678878

(no title)

pvinis | 1 year ago

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.

discuss

order

gorjusborg|1 year ago

I'm not convinced either.

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.

pvinis|1 year ago

which vscode extension do you use? I remember the neovim one was buggy with selections, so I use the other big vim extension, vsvim or something.

cevn|1 year ago

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.

Zed sees that whole string as one word object..

rbits|1 year ago

I don't know, multiple people editing the same file sounds like it would be hard to implement in nvim. Idk though, I don't know how they work.

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.

srid|1 year ago

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.