With Rust I've accepted the reality that I cannot simply survive with plain Vim. So using more and more Helix with that. I don't GUI and I dislike NeoVim so Helix has started to stick on me over the last year more and more.

One feature that I like a lot in Helix is "no plugins" ;-) That's fresh. One thing that I wished it had, and thus not applicable for kernel development, is the support for ".editorconfig". Once it has that I can try to write a kernel patch with it.

#helix #vim #editor

@jarkko I've being using vim/neovim for more than 10 years, and it's the first time that I hear about helix.

Somehow I'm quite impressed that whenever you press some shortcut, it shows the available options (like pressing g and seeing all possible movements possible, like list line, or first file of the file).

Thanks a lot for sharing! It seems much more polished than having neovim plus a ton of plugins!

@mpdesouza different key strokes is not that confusing after a while. i still love (non-neo) vim for raw text editing, and different strokese actually help me to be aware which editor I'm using ATM :-) and helix has very intuitive contextual help system.

There's also PR for editorconfig so I guess that some day that will land too https://github.com/helix-editor/helix/pull/1777/

Plugin systems sort of make everything as a programming language. I like the simplicity of "opionated" features even if one knob that i'd like to be there is missing. It also gives guaranteed ubiquitos UX when i login to different systems as everything has the "same plugins".

@jarkko I agree! For now I've being using the common features, and it already has working git gutters, and compile_commands.json out-of-the-box, so I'm quite impressed.

@jarkko May I ask why exactly you don't like NeoVim?

@wren3n it breaks the bits that i actually use :-) e.g. elevated commands (you can sudo in ex) and remotes. and plugins often makes it not work like vim i.e. make it something else than vim is. i've been a vim user since 1998 so in that time you get into habbits :-) actually a completely new thing but still modal is easier to get off those habbits. it's totally subjective thing really.

@wren3n also vim already had too many features, so for it never made sense to break the old ones and pile bunch of new ones on top... it is called inconsistency in my books :-) making something completely new from clean slate is something i get much better. and for terminal.

@mpdesouza So I did a kernel workaround in .config/helix/languages.toml:

[[language]]
name = "c"
indent = { tab-width = 8, unit = "\t" }

:-) I mean I rarely use anything else than kernel convention for any C code not a big deal… Still would be nice to have editorconfig eventually for some contribution or something.

For using compile_commands.json with kernel this the workflow I’ve ended up with:

make ARCH=x86_64 O=./.clangd x86_64_defconfig                                       
make ARCH=x86_64 O=./.clangd menuconfig
make ARCH=x86_64 O=./.clangd -j`nproc`
scripts/clang-tools/gen_compile_commands.py -d ./.clangd

This way it does not confuse e.g. BuildRoot when I point out my BuildRoot with LINUX_OVERRIDER_SRCDIR to my local kernel tree. Not sure if there is better way to do this but feels like a working workflow in my case.

Nice to see some real innovation with Rust in text editors instead pwning the GPU or similar features. If you editor will not work in terminal, it will end up sucking in the end, as far as I’m consdered :-) Not minding of having also GUI but first things first…

@jarkko interesting, thanks a lot for sharing your setup. I never really used clangd, so maybe now it's the time to do it properly :)

@mpdesouza I gave a test run for a (trivial) kernel patch: https://lore.kernel.org/linux-integrity/20241113002414.609168-1-jarkko@kernel.org/T/#u

Was not a bad experience and finding files with <space> + f was convenient. Will try another time.

@jarkko Is Helix able to support auto-completion in the kernel? Or at least something like, jumping into the function header or source?

I'm really looking for those features in an editor recently (or I will have to wired something in my Neovim config)

@mairacanal Yes.

You just have to generate the compile_commands.json manually as shown by my example in this toot. That is the file that will be recognized by clangd (the LSP server for C). You have to build the kernel first so thus I have that separate "LSP build" stored under ".clangd".

For anyone who cares my helix config is available at: https://codeberg.org/jarkko/skeleton/src/branch/main/.config/helix

@mairacanal After knowingly realizing the different order of vim and helix I don't find too complicated to use both either. Vim is "do-select" and helix is "select-do" :-) That's the main philosophical difference.

@jarkko That sounds perfect! I'll give it a try today. BTW I also use Catppuccin Mocha, great theme

@mairacanal yeah, i agree! I like it because it is the only theme where both light and dark versions work for me :-) while hacking i like to use dark and while in meetings and in presentation slides the light version is great

@jarkko I'm just back to say that I moved to Helix for real. I even deleted my almost 10 years old vim/nvim config files.

Also, clangd worked like a charm, and I don't see myself working on kernel code without Helix anymore (for real, how could I live without LSP for this long??).

Thanks again for sharing your experience with Helix!

@mpdesouza With Rust it becomes quite difficult to navigate in large projects unless there is LSP or similar. With kernel you can go far with git grep ;-) The reason is that even a simple Rust project can connect to hundreds of crates through the dependency graph as the app executable model of Rust is essentially huge static blob.

@jarkko interesting, I've never really programmed in Rust, but it is good to know that Helix's LSP will help with that :)

@mpdesouza I've been writing a feature patch set for kernel for first time for a long time and in that I've noticed that LSP is really helpful to on navigating around the tree :-) Makes it considerably a faster process because before I would have used mostly https://elixir.bootlin.com/linux/v6.11.8/source. For bug fix I might grep like a portion of a log message string or something like that.

One non-LSP thing I've liked once I got over how weird it was first, is multi-cursor/select approach for search replace. If ":q" was important for Vim, for Helix the important key stroke to keep in mind is IMHO "," because it can be trippy if you accidentally end up to the multi-cursor mode ;-)

@jarkko the multi cursor together with the LSP is amazing. And as you said, git grep works, but always felt kind of clumsy, but with LSP I feel with superpowers :)

Also the Space - k (documentation) is truly great for nós macros and library functions. As I said, Helix was something that I've been waiting for for a long long time :)

@jarkko also, yes, I've stumbled a couple times with the multi cursor without knowing how to get it back to one cursor, it fortunately the Helix keymap docs are truly useful :)