Live data from Hacker News

Leaving Neovim for Zed

stevedylan.dev

81–90 of 331 posts

Re: Leaving Neovim for Zed

#81
post #62
post #41

Most of the negatives mentioned (fragility, bugs, plugins breaking often) are specific to neovim. It's one of the reasons why I am and will always keep using vim instead of neovim. Vim is a much more mature ecosystem, less chasing the newest "plugin du jour", my vimrc is stable, based on a few dozen plugins which are feature complete and rock solid stable.

neovim is what happens when the javascript kids decide to "improve" one of the best editors ever created. The entire Lua ecosystem standing on 50 unstable plugins that provide the entire kitchen sink, yet do not even have a 1.0 version is nightmarish. Follow any guide and either everything breaks, or you get an hodgepodge of automagic popups, stuff that autodownloads, flash messages and useless features that are comp…

I am not a JS dev, and still prefer nvim. If you’re careful with plugin choices, you can get nice QoL features and still be stable. I can’t think of a time when I’ve had nvim crash.

You’re correct that random guides are generally garbage, but by reading plugin docs (gasp), you can generally get stuff working without much fuss.

Re: Leaving Neovim for Zed

#82

Over the summer I got an interest in Kakoune and Helix and discovered a number of extensions for VSCode that enable modal editing(1), but not VIM-style per default. I got excited about this and ended up writing my own extension instead. At this point, it supports most of the VIM subset that I care about, and I have added a number of new motions and modes that do clever things based on the AST. I am kicking myself for…

That's very interesting. Very cool to look at the source and see how simple it is. I may have just answered my own question, but I'm curious why you prefer this over the popular vim or neovim extensions, which have quite good coverage of vim features, and the neovim one even lets you use real neovim plugins because it is powered by a real neovim instance.

Re: Leaving Neovim for Zed

#83

Honestly, I don’t understand when someone says VSCode is slow because it’s built on Electron. Are they talking about the 3 extra seconds on cold start? Is that really something to scoff at considering all its benefits??

Depends how often you’re opening / closing it, I suppose. I work in an nvim + tmux environment, and am frequently opening and closing single files across disparate directories, so it does matter to me. I can spawn a new pane (or split existing), open nvim, and be editing before VSC has finished launching.

Re: Leaving Neovim for Zed

#84

I tried Zed just yesterday and sadly my experience wasn’t “just works”. It just works if you haven’t used any of the Neovim configs/distributions. But for someone who already uses LazyVim, LunarVim..etc., it’s kind of meeting the expectations. The issue for me was with the Docker LSP. I have a codebase where a Dockerfile is a Jinja Template. Zed’s syntax highlighting broke at the first curly braces. Both my Doom EMac…

Is it named Dockerfile or Dockerfile.jinja?

Re: Leaving Neovim for Zed

#85
post #41

Most of the negatives mentioned (fragility, bugs, plugins breaking often) are specific to neovim. It's one of the reasons why I am and will always keep using vim instead of neovim. Vim is a much more mature ecosystem, less chasing the newest "plugin du jour", my vimrc is stable, based on a few dozen plugins which are feature complete and rock solid stable.

Not sure what this fragility is. I’ve been using Neovim from the very first days, and it’s been stable throghout.

Granted I have a 10+ year old vimrc and rarely add new plugins, but saying Neovim is fragile is nonsense. Don’t install every new plugin perhaps?

Re: Leaving Neovim for Zed

#86

Honestly, I don’t understand when someone says VSCode is slow because it’s built on Electron. Are they talking about the 3 extra seconds on cold start? Is that really something to scoff at considering all its benefits??

Depends how often you’re opening / closing it, I suppose. I work in an nvim + tmux environment, and am frequently opening and closing single files across disparate directories, so it does matter to me. I can spawn a new pane (or split existing), open nvim, and be editing before VSC has finished launching.

You can open files from disparate directories within the same VSCode instance though.. you don't need to launch a new instance for each one.

Re: Leaving Neovim for Zed

#88
post #67

Earlier quoted context omitted.

Emacs[1] has been bloated with collaboration (gnus, etc) and AI features (doctor, lisp in general) for decades! [1] Eight Megabytes and Constantly Swapping

-rwxr-xr-x 1 root 24 Oct 29 1929 /bin/ed -rwxr-xr-t 4 root 1310720 Jan 1 1970 /usr/ucb/vi -rwxr-xr-x 1 root 5.89824e37 Oct 22 1990 /usr/bin/emacs

[deleted]

Re: Leaving Neovim for Zed

#89

I’m going to somehow misuse this discussion to ask for the readership help about something: I don’t understand the appeal of VSCode or more exactly I don’t understand the appeal of the text editor propped with plugins to be a semi-IDE so I guess that would also include Neovim with plugins. In my career, I have used text editors including vim which I still very much enjoy and both Eclipse and IntelliJ when I used to c…

For me, VSCode is not a great editor. It feels cobbled together and often provides a worse development experience compared to language specific IDE

HOWEVER..

It has a killer feature if you are doing remote development.

It (mostly seamlessly) presents the remote (ssh, docker, wsl) as if it was local, and I've yet to see another editor do it as well and as cleanly.

So much so that when doing remote development I'm prepared to put aside VSCode's other shortcomings for the superior remote development experience.

For local development I still use vim+terminal, but if I'm in a situation where development needs to be done on a remote machine, the VSCode vim bindings are good enough that I'll probably be using VSCode.

Re: Leaving Neovim for Zed

#90
post #67
post #55

Earlier quoted context omitted.

To paraphrase an old quote, "every new text editor grows until it is bloated with collaboration and AI features." Thank god we still have vim and Emacs.

Emacs[1] has been bloated with collaboration (gnus, etc) and AI features (doctor, lisp in general) for decades! [1] Eight Megabytes and Constantly Swapping

[dead]
Post reply on HN