I wanted to provide an anecdote because I hold the opposite opinions of the author in a variety of ways, but still have used Helix as my primary editor for years now.

I don't chase shiny new tools nor do I aspire to replace my toolchain with things just because they're built in Rust. I've used vim/neovim ~15 years. I don't use many TUIs (I actually can't think of any others besides my editor), but my development workflow is entirely terminal-based. I use native splits/tabs in my terminal emulator instead of screen/tmux/zellij. I spent years balancing having a minimal vim configuration that included plugins (but not compiled ones so that it was portable) but didn't include hundreds or thousands of lines in my vimrc. I'm excited to see how neovim is making progress with native LSP, but for years getting it working meant continuously tweaking vimscript/lua code or adopting a massive plugin written in TypeScript.

When I first tried Helix, LSP just worked; it read what was on the $PATH and used it. That's perfect because it solves for another source of annoyance: having different versions of tools for different projects. As the author notes, there are some LSP features that don't work with Helix, but whenever I dig into the issues, I almost always come to the conclusion that the issue lies in LSP being a VSCode monoculture rather than a deficiency in Helix itself. However, using the right version of a tool for a specific project and not spending any time configuring LSP servers were the top problems plaguing my usage of neovim.

If you're a vim user and you're concerned about muscle memory, by the first week I was proficient and by two weeks, Helix was the default in my brain.

I was a huge supporter of neovim -- I actually was submitting patches to the vim mailing list to fix vim on a beta version of macOS at the time taruda posted his original async patches that kicked everything off. If you had asked me the day before I tried Helix that you could reimplement a vim-like codebase from scratch well enough to abandon the original vim code, I would've agreed with you.

▲

pretzel5297 3 days ago | parent | next [-]

> I'm excited to see how neovim is making progress with native LSP, but for years getting it working meant continuously tweaking vimscript/lua code or adopting a plugin written in TypeScript.

Lua and native LSP supports were introduced at the same time. Not getting how you would tweak Lua code to get LSPs to work before Neovim had native support.

> LSP just worked; it read what was on the $PATH and used it.

This is how Neovim loads LSPs as well. You don't need a plugin to download and manage LSPs. You can just install them externally yourself.

> not spending any time configuring LSP servers were the top problems plaguing my usage of neovim.

It's been years since it's just a few lines to enable LSPs with the config shipped in nvim-lspconfig if you don't want to override any server-specific settings. And even then its still pretty easy.

I will give you that Neovim should ship with nvim-lspconfig and just load a compatible LS if its already in the PATH. Enabling each server one wants to use is annoying. But again, it's just a few lines (and I'm pretty sure a lot of people wage war if they did either of those things because "bloat").

	▲	jzelinskie 3 days ago \| parent [-]
		I don't think my config works anymore (to my earlier point), but this is the balance I struck when I used neovim: https://github.com/jzelinskie/dotfiles/blob/426768c61078a77c... I'd explicitly configure which servers were triggered which filetypes (aka autocmd and when I first started doing this, the binding for autocmd didn't even exist in lua yet) and have to bind lsp functions to keybindings across languages. FWIW, I have no idea what I would've done in vimscript, lua is a godsend with tables, loops, and lambdas. At this point in time, I was an early adopter neovim's built-in LSP and everyone else was recommending coc.nvim. But the juxtaposition at the time was that Helix ships `languages.toml` that includes all of this already out of the box. You can override it, if you want, but actually all I wanted was cohesive keybindings for basic LSP functions. What's the state of the world for neovim today?

▲

zveyaeyv3sfye 3 days ago | parent | prev | next [-]

> LSP just worked

Hi, just browsing. Where are you usually having issues with LSP these days? Is it a vim issue specifically, or related to your setup?

I believe LSP works across a multitude of editors by now.

	▲	vaylian 3 days ago \| parent [-]
		What helix gives you is opinionated LSP support. With vim you first have to add some configuration and choose key bindings. I have used LSPs with vim before, but I wasn't sure which configuration makes the most sense. In addition, helix is optimized for discoverability: You get context menus for basic editing commands and LSP commands. This really helps with learning how to take advantage of the editor and the LSP features.

▲

christophilus 3 days ago | parent | prev [-]

I use netrw to create files, and sometimes to browse. What do you use when using helix?

▲

jzelinskie 3 days ago | parent [-]

I was never a big user of netrw or nerdtree, but Helix has <space>+f for a fuzzy-finding file browser or more recently they added <space>+e or <space>+E for a hierarchical directory explorer.

I build HEAD from source using brew, so I'm not actually sure if the directory explorer is in a stable release.

▲

christophilus 3 days ago | parent [-]

How do you create a new file deep in a nested folder? In Helix, I think I used touch from a new terminal, but that’s a pain with deep folder hierarchies when I’m already in the correct slot in my editor.

	▲	mechanicum 3 days ago \| parent [-]
		The % register contains the path for the current buffer, you can insert that into prompt commands with <C-r>%. <C-w> at the command prompt deletes the last word, which in this case will be the filename of the current buffer, leaving the directory path. So: :o <C-r>%<C-w>new-filename<ret> Would open a new buffer at /path/to/the/previous/buffer/new-filename. The file isn’t created on disk until you explicitly write, so :w! to save the first time. If you literally just wanted to create a new file instead of opening a buffer, you could do that from inside Helix with :run-shell-command (aliases sh or !) instead of another terminal: :sh touch <C-r>%<C-w>new-filename<ret> The :o method has the advantage of LSP integration. For example, when I create a new .clj file that way in a Clojure project, the new buffer is pre-populated with the appropriate (ns) form, preselected for easy deletion if I didn’t want it.