Future of this project and what are the priorities, vision, goals

[gj1118]

There are so many things that I would like to get implemented but first I must set the numero uno guideline.

1. Courtesy and politeness are our foundation. Software may function or fail, but we must never lose our decency. This is our first principle, and no other rule should take precedence over it. As a diverse community, we will inevitably have our differences, but we will resolve them amicably. If we find ourselves unable to settle our disagreements in a civil manner, it is better not to create the code that led to a situation where we compromised our sense of human decency.

Civic sense + Kindness + Courtesy > A brilliant piece of code written by a savant

---

2. General Crossover between Neovim and Helix, so I can use the same plugins neovim has. Seems impossible at this point - but if we can have a facade (which will be a complex and complete project in itself) we can start small and then grow into something big.
3. LUA based plugin system ( its a language world knows, so in order to increase the adoption rates of Helix, we must be where the world is). More adoption rates will give us more contributors, more plugin authors, more maintainers.
4. Need more maintainers (short term) - applications are welcome
5. keep upto date with Helix. At some point in time , we will diverge, but till that time comes , I want this fork to keep upto date with the upstream helix.
6. Built by the community, built for the community. Of course we will hit roadblocks, of course we will have to rollback commits in main after release has been created, but I believe that will happen not too often if we are careful.
7. Its not a me project, its our project.
8. Move this repo under an organization. (org-name suggestions are welcome)
9. Always always credit the original Helix maintainers. They deserve 99% of the credits, always have and always will.

[umwwwelt]

neohelix is coming

[RokKos]

I like the name, not gonna lie 👍

[gj1118]

If I may, I would like to propose to move away from helix and neovim names altogether. I dont want to get into things in future where we are being blamed for any kind of infringement. Kindly, let me know what you think? Thank you!

[RokKos]

I believe that is very reasonable thinking!

My response was really a reaction, as I like the wordplay and if we are gonna implement Lua plugin system, then it feels the same as the Vim to Neovim switch (where they went from VIM scripts to Lua plugins).

But yeah, will think about the name and post it in the #21 discussion

[tylerlaprade]

Helix is not a trademarked name, and it is not used in commerce. There is no legal basis for any kind of infringement concern.

[sheam]

Sticking with the Bio theme, how about 'Axon'?

[RokKos]

I would love to volunteer as a maintainer 👍
To be honest, I've never been in that position, but I have quite a lot of professional experience in closed-source software.

[gj1118]

You are now officially our first maintainer. Please give me some time. I will setup an org and move this repo under that org. I will update this thread, once when I have it ready.

Congratulations. And thank you for leading this effort.
Few salient points that I will also do is

1. No code merges will happen (even from me ) without both of our approval.
2. All code changes, plans , you will have now have to provide your inputs as well. We cannot release software, till our maintainers are on board.

Also please let me know if I am missing something.

Thanks once again. Welcome to the bandwagon !!

[gj1118]

I updated the original post. Thanks

[RokKos]

I've had some more time to think about the project, and I'd like to share my personal opinions on the priorities, vision and goals.

Addressing your bullet points @gj1118:

1. I agree with this statement and support it.
2. and 3. : I would prioritize a Lua plugin system built on the API created for the Steel plugin system (as a stage 1 implementation and then in stage 2 do neovim compatible API). As I belive that this would open doors to more plugin contributors in the short term.

I briefly checked the Steel plugin implementation PR: helix-editor#8675

And design notes indicate that it's open to other scripting languages. This seems promising:

Given prior conversation about developing a custom language implementation, I attempted to make the integration with Steel as agnostic of the engine as possible to keep that door open.

and this:

On top of that, I believe what I have allows the coexistence of multiple scripting engines, with a built in priority for resolving commands / configurations / etc.

We would also need to decide what the language is for the config files.
I really like toml file format, for its simplicity. That is one of the reasons why I decided to stick with the helix editor.

A potential model could be:

• toml for configuring the editor and plugins.
• Lua for the plugins themselves (which could export their own configuration options).

4. Definitely!

5. I agree we should try to stay up-to-date with upstream Helix development as long as possible. This gives us "free" development power from maintainers and community PRs.

However, we also need to assess the cost of maintaining this. We need to be mindful of how hard it is to maintain the fork. The Neovim community, for example, decided a large refactor was necessary because it unlocked significant new capabilities for them.

I think @gj1118, you are best to judge this, at this current state in time, as you were merging both codebases.

6., 7., 8. and 9. I totally agree!

10 Additional topic: Core vs. Plugin Scope
We also need to define which features belong in the core project and which should be plugins. I see the core Helix maintainers have already drawn some lines (for example, this PR: helix-editor#5768 (comment) and also others that we merged in this project).

We should decide:

• What are the general improvements that all users would benefit from as "default" behavior?
• What features should be plugins that only a subset of users will use?

There is a significant benefit to ease of maintenance if we delegate more functionality to plugins rather than to the core.

[gj1118]

Thanks @RokKos for the detailed comment. Much Appreciated. However I have a concern. This concern arises because I have limited understanding of the steel plugin system. So please pardon my ignorance.

If the steel scheme is open to other scripting languages, then does the following hold true

1. user writes a lua plugin
2. it gets forwarded to the Steel system
3. Steel system will executed it

If so , then I am not sure , if I like this proposal because in that case, we are depending on the steel system for proper execution of the plugin. If the steel system had a bug, but helix architecture and our plugin had no code issues, even then we will be blocked. Also our plugins will be slower.

Do you agree with this concern? Or are my concerns invalid. Please excuse me , If I asked something that is not correct. As I said, I am not very well versed with the Steel system.

Also if I may ask please - an you forward me the Steel plugin pull request please?

[RokKos]

Hi @gj1118, valid concern, but I believe if we do the implementation right, there won't be any Steel involved in the process.
Let me try to explain more about how I currently see the Steel plugin system and its implementation.

First things first, Steel plugin implementation PR: helix-editor#8675

Based on what I read and how this PR is presented, I created my mental model of how this plugin system works (it might be wrong and I will do more research). How I currently understand is as follows:

1. User writes a Lua plugin
2. We would need to implement a Lua runtime or take an existing crate that does that
3. The Lua plugin would call exposed API functions in Helix core. These functions were exposed in the Steel PR, and Steel is also using them

TLDR: We wouldn't use Steel at all; we would just use the API provided.

Why am I thinking like that, as in the description original PR, also mentioned this at the end:

If Steel is not chosen and a different language is picked, in theory, the API I've exposed should do the trick at least with matching the implementation behaviour that I've outlined here.

[RokKosSloyd]

Checked the code from the PR:

• in helix-term/src/commands/engine.rs

pub enum PluginSystemKind {
    None,
    #[cfg(feature = "steel")]
    Steel,
}

pub enum PluginSystemTypes {
    None(NoEngine),
    #[cfg(feature = "steel")]
    Steel(steel::SteelScriptingEngine),
}

And most of the code that we would need to adapt is in helix-term/src/commands/engine.rs. So we would just make a separate folder with Lua scripting engine. And we could even support both plugin systems (not sure if the best decision).

If I will have time this week, I might merge this PR into my personal branch and start exploring the possibilities and maybe make a tech demo.

[gj1118]

Love the direction @RokKos . Makes perfect sense. as long as we are using the API directly we are golden. this does resolve my concern earlier of residing on top of the steel eco-system.

[sheam]

Do we want to language engines in the built executable? One option would be to strip the steel interpreter, and just use the API the implemented. However, if the OG Helix project finally launches a version with a plugin system we would not be able to use those plugins if we remove Steel support....

[avpcretois]

Sorry I'm late to the party.

Addressing the @gj1118 original bullet list :

1. I totally approve.
2. I'd love to have access to Neovim plugin ecosystem in Helix ! The project may be very hard (especially those which modify the editing behaviour).
3. Lua ❤️
4. Absolutely! I'd also love to contribute to the project. I'm currently learning Rust and I'm not able to propose or review a complex PR yet. As an experienced engineer on close-source software, I could help in other ways for the time being.
5. Helix editor is great and I would be a shame to not use its codebase as long as possible. We could also upstream some of our modifications if possible.
   If I remind correctly the Neovim community refactored the codebase because of a good chunk of legacy code for obsolete architectures. Hopefully, Helix isn't in the same state.
6. As any software 😉

7, 8, 9 I'm completely with you on these statements !

About the 10th point raised by @RokKos I like the fact that Helix is minimal (but open to extension).
As a java developer, I only have two pain points : the lack of a way quickly new classes (without navigating in the directory hell which a Java project is) and the fact that the Java LSP has non standard extensions. I agree with the Helix maintainers about the fact that non-standard LSP features should be handled by plugins.

[sheam]

If the plugin system resembles neovim's in anyway, I'll start using MS Notepad. :)

[sheam]

My neovim plugins and config got so complex I had to keep it in a git repo. Even then everytime I setup a new machine it was a bunch of F'ing around to get it working with all plugins, lsp's etc. Not to mention the config was spread out, so that you almost need and IDE play with the config/plugins/keybindings, etc.

Not to mention that there 20 different plugins to accomplish anyone 1 thing, but now I have determine which one to use, which one will be deprecated next, week, etc.

Then the plugins can be installed manually, or with one of thirty-eleven different plugin managers, and sometimes the plugin comes with instructions for one plugin manager but not another.

Now, plugins dependent on other plugins.... and usually as a user I have to make sure the dependencies are installed.... this isn't setting up an editor, this coding your own editor FFS.

I am fearful that the plugin system may make things worse.... I am all for a less powerful plugin ecosystem, that is SIMPLE.

Please for the love of god, do not attempt to support neovim plugins. That system should be used as a lesson in what not to do.

I also see people complaining about the use Lua. Lua was built for this: small surface area, easy to bind to from other languages, etc. I don't love the language, but it is what it was meant for. Not sure why they chose Steel.... just a waste of brackets. :)

I would add DOCUMENTATION to your list of goals. With all the PRs goin in on this fork, the docs are not being updated with new config options and keystrokes.

[axodentally]

I support the call for more and better documentation :)

[gj1118]

Sure, thanks for letting me know about the lack of documentation. Can I please expect a PR please? Some help will be much appreciated. Thanks

[sheam]

I would think any PR that people introduce a feature on should include documentation on that feature before the PR is accepted, rather than have one person document anothers feature.