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

261–270 of 331 posts

Re: Leaving Neovim for Zed

#261

Post by ctenb »

imjonse wrote: post #230
petre wrote: post #221

Earlier quoted context omitted.

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

You may want to check helix.vim. it's a vim script that emulates helix

Re: Leaving Neovim for Zed

#262

Post by ctenb »

_7tgr wrote: post #164
lwhsiao wrote: post #148

Earlier quoted context omitted.

Big fan of helix and am in this camp. Used to have a bunch of plugins for neovim, but in Helix, honestly just haven't felt the need for anything besides what it comes with. It's a great editor.

I think you only miss (or at least I noticed this happened to me) a plugin system when you've engaged with the programmable side of your editor and then have to use one that isn't. I dont use/try to stay away from using (neo)vim plugins but I do like to pull out repetitive things into little snippets. I have things to manage my clipboard, pull up manpages in another editor tab when I put my cursor over a command and…

Many helix users have their own fork to scratch that itch. I do too, and it's nice, but of course a little more maintenance than a set of scripts

Re: Leaving Neovim for Zed

#264

Post by _7tgr »

ctenb wrote: post #262
_7tgr wrote: post #164

Earlier quoted context omitted.

I think you only miss (or at least I noticed this happened to me) a plugin system when you've engaged with the programmable side of your editor and then have to use one that isn't. I dont use/try to stay away from using (neo)vim plugins but I do like to pull out repetitive things into little snippets. I have things to manage my clipboard, pull up manpages in another editor tab when I put my cursor over a command and…

Many helix users have their own fork to scratch that itch. I do too, and it's nice, but of course a little more maintenance than a set of scripts

I think a big missing piece with writing what you want in Rust and recompiling the editor to activate your changes is that you're not able to work with it _live_. That is, I can use the vim (or nvim or emacs) GUI/text processing/IO/etc facilities interactively as I'm writing my snippets to see if everything works the way I expected. I can send lines/expressions to the lua/elisp compiler running in the editor that I'm _currently using to write the program_ to change how it works, _on the fly_. It's an integrated programming experience in a way that very few things are--- it's not just about programmability, but this circular thing that goes on with editors that really fully commit to it.

Re: Leaving Neovim for Zed

#265

Post by _7tgr »

imjonse wrote: post #228
petre wrote: post #226

Earlier quoted context omitted.

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.

I wouldn't really count that as editor config. Every editor with treesitter support will have configs for treesitter, for instance: https://github.com/nvim-treesitter/nvim-treesitter/blob/mast...

Re: Leaving Neovim for Zed

#266

Post by _7tgr »

ulbu wrote: post #200
_7tgr wrote: 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.

scheme is a group of languages, it doesn’t have its speed. some implementations are very quick. and quick-to-learn, too. helix looks like a passion project, so i thoroughly understand their wish to tend towards what they enjoy doing.

I mentioned speed because they're writing their own instead of using Chez or Gambit or something (which have taken a while to get into 'performant' territory). Writing and maintaining a fast(!) Scheme is hard. Having spent time with r5/r6/r7rs (many variants for the latter) and their quirks I'd honestly say Lua is simpler by a wide margin, but some of this is down to preference. The Lua execution model, if nothing else, is a lot easier to understand than call/cc for instance. And the language does force you to write things functionally, practically speaking. I'm also not a huge fan of syntactic macros. Also things like dynamic binding which, in fairness, are just SRFIs but end up being implemented by most Schemes. I do respect their willingness to do what's fun for them, though :) that's what it's all about.

Re: Leaving Neovim for Zed

#267

Post by GuB-42 »

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…

It is true that most part of software development happens in the mind, but sometimes, the mind needs a support. Some use a pen and paper, some use specialized software, but for many, the text editor is that support. That's where they throw their ideas, sometimes in code, sometimes as a comment, or in a scrap file.

Seen as a support it is important for the text editor to be as unobtrusive and responsive as possible, to not break the thread of thoughts. And slowness, even micro-stutters do that. Mastering the keyboard, which include knowing shortcuts, touch typing and generally typing fast also helps, so you think more about the problem and less about the keyboard when writing down your ideas.

Now, if the way you code looks like you are meditating in front of the screen, not typing anything but the final solution, and I am sure some people do, then you probably don't need to work fast in the editor. To each his own, but personally, speed is an important factor in choosing a text editor. That's why I am currently on Sublime Text and not VS Code. Even though the latter is similar but free, more popular, and with interesting features, Sublime Text is faster, and I like speed. And may take a look at Zed, now that it is available on Linux.

Re: Leaving Neovim for Zed

#268

Post by skydhash »

konart wrote: post #253

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

I just drop back to the terminal and use git itself (or install Fugitive). What I like about Vim/Emacs is how easy it is to tailor them to your usage patterns. Boilerplate generation, tools integration, and other programmable workflows can be quickly implemented.

Re: Leaving Neovim for Zed

#270

Post by skydhash »

__alias wrote: post #240

Has anyone made the transition from VS Code to NeoVim or Zed and succeeded / recommend it? Years ago I saw a colleague operate as an absolute beast using VS Code with vim bindings and it was impressive to watch. But I've never watched anyone code in vim/emacs etc and felt it's a more effective editor than vs code.

I made the switch from notepad++/sublime (even atom did not exist at the time). The plus side was quick editing. Most of the time you spend on a code is rewriting it (excluding reading it) and vim binding made that a breeze. And even tools provided by IDEs can be great for code massaging, VIM is still king for raw editing. And if you know the shell, you don’t miss much from IDEs.

Nowadays, I’m exploring emacs because of how easy it is to build tools in it. Vim is great for working on text, but emacs is great for creating tools that work on text.

Post reply on HN