A super fast, advanced modal editor/IDE, written in #rust and *with* #vim keybindings. How does that sound?

Some years ago, I forked the #helix editor and started adding some VIM keybindings to it. Now, some keybindings and a modeline later, I‘m excited to share #evilhelix with you, looking forward to your feedback!

https://github.com/usagi-flow/evil-helix

GitHub - usagi-flow/evil-helix: Bringing the Helix editor to the evil side

Bringing the Helix editor to the evil side. Contribute to usagi-flow/evil-helix development by creating an account on GitHub.

GitHub

@nehu if helix adds a scheme based plugin system, will you at least keep it as an option? In theory it's just an API.

I'm mostly asking because I'm curious to use a lisp editor that is not as crusty as emacs.

I'm currently a neovim user and using lua would be fine if it weren't for the decades of cruft of vimscript and super weird configuration system.

Like, every plugin defines its own way of setting up. Some use the pattern of a .init() function, others use a global variable.

@nehu and I totally agree with you that an editor must have modern basic futures built-in, like an LSP client, syntax highlighting, etc.

Some stuff is better as plugins and I'm fine with that. What is blocking me from using helix is extensibility.

For example, I need to have an integrated terminal in helix. While this could obviously work just fine as native code, I understand the hesitation to add it.

By having plugins (and a great extensible buffer system like emac's) I could do it myself.

@diegovsky Thank you for your feedback! It helps me understand what people are looking for. I don‘t plan on throwing away the plugin system, once it comes, because that would mean that evil-helix would deviate much more from upstream Helix. However, I‘m sceptical regarding the upstream intention to replace the simple, declarative TOML config by a scheme script. I‘d like to keep supporting the TOML config, ideally in addition to the scheme-based system.
@diegovsky That said, at this time, it‘s difficult to tell exactly what will land in upstream Helix, and what the impact will be on evil-helix.
Either way, we‘ll have to carefully decide between what users want, and compatibility with upstream. A hard fork would imply a lot more maintenance effort, and therefore would be my least favorite option.
tl;dr: Let‘s see how things evolve and please keep giving feedback. :)