Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leaving Neovim for Zed

stevedylan.dev

Post reply on HN
Print view View original

251–260 of 331 posts

Re: Leaving Neovim for Zed

#251

Post by _xiaz »

owenpalmer wrote: post #208
kstenerud wrote: post #191

> 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.

>finished code

I think the commenter suggests that you can just write those right away and the 100s of lines along the way don't exist

Re: Leaving Neovim for Zed

#252

Post by kristiandupont »

dcre wrote: post #82
kristiandupont wrote: post #26

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.

I was using the other vim extension for years. I had tried the neovim one as well a few years ago and I ran into so many bugs that I switched back after 1/2 day. I am sure it's better today, but I can see that there is still an open issue with folding, for instance.

The thing is that I used to consider headless Neovim to be the ultimate solution to "vim but with IDE conveniences" but I am no longer so sure. Keeping everything in sync between the two editors just seems like a task that's doomed to fail in many small paper-cut like ways. What I am doing now is much more like adding a few things on top but leaving VSCode in charge, letting it do its thing the way it was designed to.

Re: Leaving Neovim for Zed

#253

Post by konart »

>What normally required multiple plugins in Neovim is again ready out of the box with Zed, including feature like toggling Git Blame, viewing diffs, and gutter symbols showing the status of edited lines.

Pretty sure Gitsigns for neovim can do all mentioned (diffthis, blame line of file adnd obivously gutter symbols).

But if you need more you have Diffview and other plugins.

Re: Leaving Neovim for Zed

#254

Post by tmtvl »

lelanthran wrote: post #216
ReleaseCandidat wrote: post #213

Earlier quoted context omitted.

> Emacs `M-x sql-connect` is much easier for me to do than to look up, in VS Code, what shortcut has been assigned to the extension I use that does the same thing [...] > removes the whole command interface `C-shift-P` works the same in VS Code (and other editors) as `M-x` in Emacs. VS Code (and many other Editors, like Sublime Text) has the same "keyboard only" usage possibility as Emacs. I've switched from Emacs (a…

> `C-shift-P` works the same in VS Code (and other editors) as `M-x` in Emacs. I slightly disagree with this assertion. I upvoted you anyway because I think it's mostly correct for those who aren't full into Emacs :-) My reason for disagreement: `M-x` in Emacs gives you access to every single thing that the editor can do (like the function to move the point forward with `forward-char`). The `C-s-p` in VSCode doesn't…

As long as we're being pedantic: M-x only gives access to every single interactive function (which means every function which has the `(interactive)` statement). I can't speak as how to that relates to Microsoft VS Code's 'C-s-p' though.

Re: Leaving Neovim for Zed

#255

Post by rs_rs_rs_rs_rs »

p4bl0 wrote: post #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 f…

Kate can be great but it's riddled with bugs and advertised features that a completely broken(like sessions)

Re: Leaving Neovim for Zed

#256

Post by nirui »

alberth wrote: post #12

I initially loved Zed. But as their focus has shifted to building Collaboration & AI features, and still haven’t yet nailed just being a good/great base editor, its become less useful to me. I still have a lot of hope for Zed. But for the time being, I’ve switched back to my old editor & IDE … and I’ll try Zed again at a much later date.

There are many great editors out there, some free some not. If a newcomer wants to break into the market, they need to add something new to the table. Understandably, in this day and age, it might be AI. Plus, they need to find a way to make money, offering collaboration and AI related feature might enable that.

I tried Zed for one day, without collaboration or AI enabled. It has some un-rounded edges, for example, the scroll bar in some window frame don't even work, but I can still get some job done with it. I use VS Code daily, Zed reminded me how a faster and snappy interface should make me feel. I hope Zed succeed.

Re: Leaving Neovim for Zed

#257

Post by setopt »

kstenerud wrote: post #237
Jare wrote: post #222

Earlier quoted context omitted.

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, wit…

Hmm... This might be where my process differs, I guess? In my normal process (not exploratory work), I don't write a single character until I'm sure of how the thing I'm making will fit into the overall design (such as the API it will have, how it will interact with other components, its placement in the overall architecture, what its responsibilities are and how to structure it so as to minimize potential confusion…

My process is in that case quite different. When working in Python I’ll typically write thousands of tiny snippets of code directly in the interpreter to check that simple things work as I expect. Those are gradually distilled into parts of a .py file with accompanying pytest tests. Then those are refactored into classes and separate files as needed. Overall, I think I type and edit way more than you :)

Re: Leaving Neovim for Zed

#258

Post by empthought »

Zambyte wrote: post #199
kstenerud wrote: post #191

> 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.

The highest risk in writing code is that the code written will have a negative value; i.e. it will incur more development cost over its lifetime than it will recoup via its intended effects.

Hastily written, poorly justified or reasoned code has a much higher likelihood of having this flaw, so that’s why I would say you are wrong about this.

Re: Leaving Neovim for Zed

#259

Post by vaylian »

svlasov wrote: post #233
kstenerud wrote: post #191

> 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…

If you know what you want to build, typing becomes a real bottleneck.

Plus, the more ground you can cover until someone interrupts you, the better.

Re: Leaving Neovim for Zed

#260

Post by neonsunset »

meitham wrote: post #194
kstenerud wrote: post #191

> 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 don’t touch type and I’m fully with you on speed doesn’t increase performance, but I have recently started writing c# after two decades of python and man the number of lines that you have to write before you get to the meat of the logic! So I think that 10 lines of code are only to expressive languages not globally

Could you post an example of the boilerplate you are facing with? I’m sure it’s something that's perfectly avoidable.
Post reply on HN