Live data from Hacker News

Leaving Neovim for Zed

stevedylan.dev

221–230 of 331 posts

Re: Leaving Neovim for Zed

#221

Earlier quoted context omitted.

Helix has been trying to implement a plugins system for like 2 years that should tell you everything you need to know about its future prospects

A plugin system is much less of an issue when Helix has built-in functionality for most of what comes as plugins in Vim. That said integration with git or with code assistants/chat is something that is probably better done via plugins hence it is still on the roadmap. But in my experience of ~10 months of Helix vs +20 years of Vim, the former is a much more pleasant and hassle-free experience, mostly because of it of…

I tried to use it for multicursor editing which I tried to enable in Vim via plugins and it sucked, but being a console editor didn't help much. So I'm still using vi/vim for console editing because it's installed everywhere.

Re: Leaving Neovim for Zed

#222

> I was already a keyboard maximalist from previous jobs where I learned speed = productivity I've never understood this. In over 30 years in the industry, I've not once held a job where my keyboard speed had a noticeable effect on my productivity. Even when I had to type one-handed for a month, my productivity was unchanged. The average developer averages 10 lines of finished code per day. And even with a raw 10x th…

> The average developer averages 10 lines of finished code per day This is a ridiculous statement. Citation needed.

Hopefully it's clear that:

- code is not the only output produced by a developer. Communication, design, documentation, testing and tests, diagnosing and debugging, etc.

- I can and do write hundreds of lines of working code in a given day (and I'm not an IC). But "finished" was meant to describe something that doesn't get touched again unless new work requires it. A lot of code today is written more iteratively, with mvps, experiments, baselining, refactoring, etc. An mvp is not (yet) finished.

- 10 lines may be a low estimate today, but 100 is probably fair. (yeah varies a lot with language, boilerplate, etc)

I hope the general agreement would be that the amount of characters of code written is definitely not the largest part of a developer's output, but reaching the point where a given line of code is "finished" involves a number of processes and lot of typing. And editors are an important part of many of those processes.

Re: Leaving Neovim for Zed

#223

> I was already a keyboard maximalist from previous jobs where I learned speed = productivity I've never understood this. In over 30 years in the industry, I've not once held a job where my keyboard speed had a noticeable effect on my productivity. Even when I had to type one-handed for a month, my productivity was unchanged. The average developer averages 10 lines of finished code per day. And even with a raw 10x th…

> 90% of software development happens in the mind. Why? The only reason I can think of for this to be true is when there is high risk in writing wrong code. For example, long compile times leading to a large sunken cost, or a lack of testing processes. Unless you're doing R&D, only spending 10% of your "coding" time actually writing code seems very low, and you should try to optimize the processes that are lacking.

I personally have a pipeline of multiple tasks I'm thinking about in background. It easily could take a week to get details in my brain. During coding I get already worked out tasks. Most of the time it's a final design. My colleagues considers me as a 10x developer. 10% coding looks very real in my case.

Re: Leaving Neovim for Zed

#224
i wish i could speak in length about how the ide i use helps me be the "10x" dev i am clearly not.

i would say this as a mid-level dev in a team spread across geographies, however: when using a workflow that should work for all, it is more important to have a tool that works for all rather than the "best" one.

unfortunately, neither (neo)vim nor zed seem to be in a place where an entire team could easily adopt to its workflow. the latter probably needs a while to marinate and become suitable for most.

Re: Leaving Neovim for Zed

#225
post #217

Earlier quoted context omitted.

They already have Scheme based config files and I'd say it is simpler that Lua.

It can't really be simpler than Lua, come'on. Maybe if you already know Lisp, but for people who know C-like languages (Java, Javascript, C++) Lua should be much more "obvious".

[deleted]

Re: Leaving Neovim for Zed

#226
post #166

Earlier quoted context omitted.

And, oddly, they chose to do their own Scheme implementation for it. Not that I'm against Scheme in particular, but a lot of other people justifiably seem to be. It doesn't have the speed or learn-it-in-10-minutes of Lua (nvim) or the historical excuse of Elisp/Vimscript (emacs/vim) or the ecosystem of Typescript (vscode). Strange choice.

They already have Scheme based config files and I'd say it is simpler that Lua.

What are you talking about? It uses TOML for config files and some S-expressions for queries, which is actually a consequence of using tree sitter.

https://docs.helix-editor.com/configuration.html

Re: Leaving Neovim for Zed

#227

> I was already a keyboard maximalist from previous jobs where I learned speed = productivity I've never understood this. In over 30 years in the industry, I've not once held a job where my keyboard speed had a noticeable effect on my productivity. Even when I had to type one-handed for a month, my productivity was unchanged. The average developer averages 10 lines of finished code per day. And even with a raw 10x th…

I think this is a gross generalization.

In my present work at DevOps, I could say it’s true IF we only look at code.

When I was doing computational intensive simulations, I would write clearly 100 or more lines of code everyday.

Re: Leaving Neovim for Zed

#228
post #226

Earlier quoted context omitted.

They already have Scheme based config files and I'd say it is simpler that Lua.

What are you talking about? It uses TOML for config files and some S-expressions for queries, which is actually a consequence of using tree sitter. https://docs.helix-editor.com/configuration.html

I should have specified internal config files for the runtime queries that you mention. Those are .scm files.

Re: Leaving Neovim for Zed

#229
A lot of editors are being discussed here but I see nobody has mentioned Kate (KDE's Advanced Text Editor) [1] in the conversation yet, so I'm doing it. Kate is a very mature and capable editor, and even if I only use it on Linux I'm glad to know that it is also available on macOS and Windows. It natively supports LSP and has much, much more to offer in terms of project management, support for build system, support for working with Git (it's actually the only Git GUI that I found to be usable), SQL databases integration, and of course, advanced editing features. I started using it a few years back after a very long text editor journey: on Windows a bit more than 20 years ago: Notepad, HAPedit, then Notepad++ ; then I got a Mac and used TextMate (which introduced me to powerful text editors) for a few years ; then I switched to Linux ~15 years ago and used Gedit for a few months before diving head deep into Emacs and stayed fully there for… 12+ years (I actually still use it from time to time, but it's less and less the case and most importantly I stopped doing everything in it including my email, social networking, IRC, etc.) ; and now for a few years I've mainly been using Kate (and Kwrite for quick edits + Nano [2] in the terminal or on remote hosts). I even contributed a few features [3] to the project, KDE developers are very welcoming!

[1] https://kate-editor.org/

[2] I must say here too that Nano is actually an underappreciated gem. It supports a lot more features than people generally imagine: syntax hilighting, line numbering, auto-indent, multi buffers, mouse support, keyboard macros, … it's actually a decent simple code editor!

[3] https://kate-editor.org/post/2022/2022-08-24-kate-new-featur...

Re: Leaving Neovim for Zed

#230
post #221

Earlier quoted context omitted.

A plugin system is much less of an issue when Helix has built-in functionality for most of what comes as plugins in Vim. That said integration with git or with code assistants/chat is something that is probably better done via plugins hence it is still on the roadmap. But in my experience of ~10 months of Helix vs +20 years of Vim, the former is a much more pleasant and hassle-free experience, mostly because of it of…

I tried to use it for multicursor editing which I tried to enable in Vim via plugins and it sucked, but being a console editor didn't help much. So I'm still using vi/vim for console editing because it's installed everywhere.

My first multicursor experience is with Helix (it goes to show what it means to have it built in instead of trying to find plugins for it) so it may be unsatisfactory for people who have used similar functionality in other editors. I use it in a very basic way - like change similar things on related lines - but it is a nice enough feature for me to mention it as part of the batteries included Helix experience. My main issue now that I am using Helix locally is that its keybindings are not well supported in other places I occasionally work (VSCode, Google Colab) and I keep having to mentally switch between vi/hx bindings. Not a hindrance enough to go back to vim though.
Post reply on HN