Using Lisp dialect as a language of choice for plugin system is a bad decision

[synalice]

This thread is a continuation of the following discussion:

• Add Steel as an optional plugin system #8675 (comment)
• Add Steel as an optional plugin system #8675 (comment)

Making plugins should be easy

Plugins in any system or project are supposed to be a relatively easy way to extend or modify existing functionality. And I hope I don't have to explain why Lisp dialect is much more confusing and alien to most people compared to imperative and object-oriented Lua. Most people have never touched Lisp and aren't fond of learning it just to configure their editor ('cos we are also replacing TOML with Scheme; wow, so many great choices).

Answering @rsmirnov90

because then you end up with the Nodejs or Python ecosystems

Except we aren't talking Node or Python. We're talking about Lua. Its ecosystems is doing just fine.

The worst possible decision an open source project could make is chase popular tech trends
[...]
I don't understand when in history has "popularity" ever been a criterion for an open source project.
[...]
Trying to see WHY on earth an OPEN SOURCE project would use this model is making my brain bend in directions that it was not designed for.

Because there is already a ton of legacy-corporate-LTS-domain-specific horseshit. People don't want to learn another domain-specific and niche language just to configure their editor. I honestly don't understand what's so hard to understand here.

Lua is easy, stable, battle-tested and it just works. That's something you really-really want from a language you are forcing upon external developers and users of your software.

Where at any point was anyone dishonest with themselves?

At the "Schemes are stupidly popular" point.

There is no other language family that comes even close for being the de-facto default for extensions for UNIX-based software as Scheme does (the other contestants being Tcl and Perl).

Wooow, bold claim. You must be really delusional if you think that in 2025 Lisp and Perl are "de-facto defaults for extensions for UNIX-based software". Was there every any poll about what Helix users think would be a good choice for a plugin language? No? Then please don't ever bring the "stupidly popular" point anymore.

Sure, blindly following masses is not a good way to run an open-source project. But choosing Lisp dialect for plugins is taking it too far.

Ah that changes everything!!!

BTW, notepad++ (which arguably was at one point more popular than neovim and helix combined) uses C++. So let's use C++!

I don't even get WTF this comment is. Is the argument that Helix is supposed to use Lua? Because it works for Neovim?Vimscript works for (non-neo) vim, and LISP works for emacs too btw. Why not suggest those? Why Lua?

And see how you had zero concrete arguments against Lua? I understand that you are emotionally attached to you language of choice, but it's best to be able to (1) support it with arguments and something factual and (2) understand that there are moments that you have to be pragmatic instead of opinionated.

The most popular languages since the 1980s were, in order: COBOL, Visual Basic, Java, and Python. If we are going for popularity, why not pick one of these?
We can also make Helix configuration XML driven (because it's more popular!)
Also I looked at a graph of OSes by popularity, and Android is on the first place. Let's rewrite in Kotlin and use XML!
BTW, notepad++ (which arguably was at one point more popular than neovim and helix combined) uses C++. So let's use C++!

I hope that I've already answered your questions about popularity and don't have to take whatever this is seriously.

(Lua, btw, is a scripting language that is meant to be very easily embeddable and callable by/from C. Nginx also uses it and it works GREAT for them. Why? Because nginx is also written in C. The NetBSD kernel also uses Lua and it works FANTASTIC for them. The NetBSD kernel also happens to be written in C. Helix, btw, is not written in C).

You know what else has good interoperability with C? Rust.

That's such a stupid argument, I honestly have no words. If you want to shill Scheme so badly, at least choose arguments that don't make it look like you have no idea what's you're talking about.

Really confusing comment indeed.

Extra

Comment about why Scheme is a bad choice:

I think a big drawback of this approach is that scheme is not a super widely used language (just a quick language:scheme on GitHub does not turn up any major projects). While it's a simple enough language to learn, it does mean that people will be less likely to write plugins if they have to learn a new language first. However, more importantly, scheme does not have the same ecosystem that rust does. In rust there are a ton of really high quality crates (examples: git2-rs/gitoxide/pijul) easily distributed with cargo.
This means that scheme plugins would heavily rely on callbacks to core API provided by helix because any other required functionality would have to be implemented from scratch.

Comment about how Scheme was chosen by a select group Helix developers in matrix channel and is now being imposed upon everyone else:

As we said often in the matrix we already decided on using a scheme. Its also why we marked this discussion as anwsersd (and posted exactly that information in the response).

A lot of people in the same matrix channel did raise concerns about Scheme's user-friendliness, but this has been ignored. All because tree-sitter runtime queries are Scheme, so there's a bit of an elegance of reuse to it.

[offsetcyan]

Scheme is awesome. Helix is awesome. If people like Helix, and they like it enough to use extensions, and they like it enough to want to write an extension - they can learn enough Scheme to write their extension. It's not like Lua or Scheme are complex languages, Lua basically feels like a Lisp without the macros. If you're really fuming over it, do like Racket and reimplement Lua in Steel. You'll survive.

Edit: Also, Lua really doesn't have an ecosystem. It has popular libraries and such but you're almost always vendoring them yourself and downloading them from GitHub/some tarball somewhere, and there's no real way to gauge what people are actually using. It's a great language though.

[mdallastella]

I believe the misconception here is about open-source meaning: if you're not happy with the developers choice, I think everyone is free to fork the project or (better) start to work on a PR to support your scripting language of choice.

[zetashift]

A hell of a way to manage an open-source project, guys :)

Ending your post with snark like this as a reply to somebody who isn't a maintainer, is at the very least distasteful. Your post could be taken better in good faith without this.

All because tree-sitter runtime queries are Scheme, so there's a bit of an elegance of reuse to it

Technically it isn't scheme, it is a form of sexps, but the .scm was chosen for easy highlighting.

Most people have never touched Lisp and aren't fond of learning it just to configure their editor ('cos we are also replacing TOML with Scheme; wow, so many great choices).

Most people aren't fond of configuring their editor at all. If you have a tiny TOML as a config, your config will remain tiny with a different syntax. And as of now, the Steel integration supports both, and I'd imagine toml rewrites can be automated.

People don't want to learn another domain-specific and niche language just to configure their editor. I honestly don't understand what's so hard to understand here.

And I understand that people don't want to do that and why. But the reverse is also true, the maintainers right now want to have Scheme so that they can enjoy and maintain an OSS(!!!) project the way that they like. Scheme is easy to parse and mold to your liking, that is the power of this """niche""" Lisp. It's okay for people to not use the popular option in the OSS world. Can you see how your reasoning applies conceptually the same to (neo)vim w.r.t. helix? Verb -> action is the unpopular option(helix) vs action->verb (vim)?

Your post in the steel PR got flack, because you complained in the wrong place. That PR is somebody who took it up themselves to make a plugin system with a scheme that integrates nicely in Rust, in their spare time, rebasing after every major (internal) change. It has been stated several times in that same PR, why Scheme; your comment added 0 technical value to that PR.
There are a lot more people hoping that PR gets through than there are people that would like to see maintainers sacrifice their time to shove in Lua against their preference.

[synalice]

Ending your post with snark like this as a reply to somebody who isn't a maintainer, is at the very least distasteful. Your post could be taken better in good faith without this.

Yes, that was too much... I am sorry.

[Jackojc]

I think it's a fine choice for a language. It's just as niche as helix is but people learned to use that. Scheme is not a difficult language and is rather intuitive and elegant.

If you just want to use plugins, you don't even need to touch it for the most part. If you want to write plugins, I don't think the language is going to be a large barrier and I think if it was, you'd also need to learn other things anyway.

Also, maybe it's worth pointing out that emacs uses lisp which is fairly similar to scheme at a fundamental level. It seems to work out well for them seeing that emacs is one of the most configurable and extensible editors out there (emacs is your OS).

[dtomvan]

The single question in my head is: why make such a fuss about it? Does this decision really matter, if you think about it? Helix already has a fine configuration system through the static TOML files. Most things you want can be done in there. So if a user really needs more out of their config, they probably know what they are doing anyways, at which point they should know their way about getting accustomed to a language they have never seen before, trivializing the difference between either language.

If we really need to compare scheme to lua, they are really similar if you think about it: they are both lightweight scripting languages, both lua and steel are meant to be embedded into a larger system/application, they are both procedural and functional languages etc. the only major difference is the syntax (which imho is a small barrier to overcome).

For what it's worth, you still see, to this day, that people are configuring their software through Lisps. Be it their Emacs config, packaging some software with guile or even defining their entire OS with it.

At the end of the day, they are both great tools for the job of writing editor plugins. Lua has worked for Neovim, and Scheme will work for Helix. There has been a lot of effort put into writing the engine for this, so our best bet is to improve upon that. I think that our time/effort is best spent addressing actual concerns, rather than "is this language the ultimate perfect choice?"

If this was a PR for configuring hx with an esolang like BQN, I think you'd have a point, as such languages handle concepts the average programmer has never seen before, and can become a frustrating experience. But the language chosen here, when you get used to the paren/indentation style, is actually very ergonomic and easy to read and reason about.

[Jackojc]

Exactly. I think any motivated developer looking to write a plugin is not going to be put off by learning a new (and very small) language at all. This is something developers regularly do anyway.

[freepicheep]

Go write a plugin system in lua for helix yourself and open a PR or maintain your own fork. Give some respect to the people writing a plugin system in Steele. Stop telling others to do things for you.

[dtomvan]

Yeah, reminds me of "Talk is cheap, send patches" 😆

[snatvb]

what the reason to write it and split the community? and this PR will not accept? it will all in vain

[darshanCommits]

I think a lot of criticism comes from the assumption that users will need to write a lot of scheme, like how they need to write a lot of lua in nvim.

This assumption itself may be the cause of all this fuzz.

And about it not being the popular choice, I'd say learning helix motions for a vim user is harder than learning a new language.
And those who weren't vim users before, probably had just as little experience with any scripting language (the "me" case) so it's starting from scratch either way.

[dtomvan]

Even with neovim, you can still get away with a couple dozen lines of vimscript, just setting some options (less and less as time goes on, the defaults are getting better and better) and running a couple Plug "..." statements. Nowadays even LSP has plugins that setup everything automatically for you. I think helix is doing that way better here though: just make sure the LSP you want to use is installed, and it will automatically get picked up. So the new user experience (except for learning a different kind of modal editor) is already much nicer for helix. Steel will not change that: it will only expand the possibilities for power users.

[a-berg]

ppl had to invent fennel because they wanted to use lisp in lua, go figure... /jk

[noor-tg]

You can fork helix. And make plugin system with lua. Let's see the effort to make something similar in your free time. Like the author of the Steel PR did.

[synalice]

I don't have anything against the author of the PR. Doing something this big in your free time is indeed an achievement.

The only complain I have is about Helix's maintainers choosing Lisp. This has nothing to do with the person integrating Steel.

Voicing that complain in the PR thread was out of place, I get that.

[noor-tg]

I don't have anything against the author of the PR. Doing something this big in your free time is indeed an achievement.

The only complain I have is about Helix's maintainers choosing Lisp. This has nothing to do with the person integrating Steel.

Voicing that complain in the PR thread was out of place, I get that.

What I mean is you can really start new pr to propose lua as plugin system lang. And if the main repo did not accept it. You can maintain your own fork.

It is an open source project.

[kirawi]

The plugin system was intentionally designed to be modular in terms of what language it uses. I don't know if that's still the case, but that's how it was envisioned. So someone could support Lua in their fork easier than what it took for Neovim to support Lua. But I'd suggest waiting and seeing how the Lisp experience goes since I honestly don't think it'll be a deal breaker.

[oiwn]

Emacs used lisp for decades and have wide, established ecosystem.

[getreu]

Was there every any poll about what Helix users think would be a good choice for a plugin language? No?

The long term success of an open source project depends on how easy it is for potential (new) developers to contribute. Forcing people to learn a new language is a hurdle that should be avoided if possible.

[dtomvan]

I am a fan of Nushell's approach to plugins
IIRC the helix developers made a decision very early on that they didn't want plugins in Rust, but something interpreted instead. This makes it faster to iterate on and because it has such quick feedback it's easy to experiment with.

But I also think that Rust plugins fit Nushell well, because they don't handle "text" or stdin/stdout, they handle "data" which is much richer most of the time, which requires a more robust interface between plugin and shell. They handle a whole bunch of things which traditional shell plugins don't do: signals, messages, JSON/msgpack, rich error types, etc. But I think that a text editor such as helix does way better with the "emacs approach".

[TeriyakiBomb]

It's the "bums in seats" argument. I think ultimately the reason why python, Lua and JS persist as the main languages is purely down to their popularity driving adoption. At the start of this thread one of the arguments against a more mainstream language was, and I'm paraphrasing "Half of the plugins will be written by middle schoolers and not maintained".

That's fine. Hell, it's desirable. In every extension ecosystem, the projects most people find most useful rise to the top and are generally maintained. Others might be useful, but half baked, so someone will revise the idea and a new plugin will emerge. It's how it's always been. You go where the people are, arguably it's more important than some niche adjacency benefits from choosing another language.

The bottom line is - if you choose python, JS or Lua there will be more plugins in the ecosystem, simple as that. With scheme, there will be less. There are no guarantees of long term support with any of these options, so go where the people are.

I'm not losing too much sleep over this, and can't wait to have plugins be part of Helix. I'm stoked the scheme PR is shaping up and getting closer to release. But still, it's not seeng the wood for the trees and won't do anywhere near as much to encourage helix adoption.

[getreu]

But I also think that Rust plugins fit Nushell well, because they don't handle "text" or stdin/stdout, they handle "data" which is much richer most of the time, which requires a more robust interface between plugin and shell.

Nushell plugins are executable applications that communicate with Nu by exchanging serialized data over a stream (much in the same way VSCode plugins do). The API is fast, robust and mature and well suited for Helix's use case. The protocol is programming language agnostic.

[a-man-called-q]

Was there every any poll about what Helix users think would be a good choice for a plugin language? No?

The long term success of an open source project depends on how easy it is for potential (new) developers to contribute. Forcing people to learn a new language is a hurdle that should be avoided if possible.

Most of web programmers in the world was using PHP or ASP back then, and those who doesn't want to learn JavaScript were left behind.

I got a quote for this comment

Humans are allergic to change. They love to say, 'We've always done it this way.' I try to fight that. That's why I have a clock on my wall that runs counter-clockwise.

[kirawi]

See #3806 (reply in thread) about serialization above

[oiwn]

I'm excited to use lisp for plugins in helix. Bring it in!

[ronisbr]

Here’s my two cents.

I believe in the Maker’s choice. So, if the developers want Steel or Lisp as Helix’s plugin language, no one has the right to comment on that unless this person starts its own PR.

That said, I personally think choosing Steel or Lisp as the first language for plugins is not a great idea. Lisp is very different from most programming languages, and I’m pretty sure it’s not used anymore except in very specific cases (like Emacs).

Neovim chose Lua. Vim started its own Vim9 script language. After a very short time, we have amazing plugins in Neovim with quality equal to or even better than their Emacs counterparts that have been developed for three times longer.

So, in my opinion, Steel or Lisp in Helix will work, but it will slow down plugin development (and by extension, the editor usage).

[noor-tg]

I am waiting for you to make lua based plugin system with helix 🤣🤣🤣

So, you’ve finally come to agree that a Lua-based plugin is indeed more promising. That’s great to know that this technical discussion has changed your opinion!

Cheers!

Naaa, I am just messing with you 🤣.

I just want to see you make a real contribution instead of yapping.

If you are really serious about lua. Make a plugin system with it. And we will see which is better.

Cheers

[snatvb]

no one has the right to comment

Everyone has the right. What kind of dictatorship is this? They have no right to force, but anyone can discuss and comment. If you don't want your work to be discussed, don't make it public. If you don't want someone to accidentally film you, don't leave the house.

[ronisbr]

I was referring to comment about the language decision on the pull request. Outside it, I fully agree with you.

[snatvb]

I was referring to comment about the language decision on the pull request. Outside it, I fully agree with you.

ah, yeah, sorry, misunderstood, then I agree with you :) PR not the place for this

[ian-h-chamberlain]

For those who are interested in using Lua for plugins, it seems like the Steel plugin architecture might actually make that feasible without too much trouble: #8675 (comment)

I can easily imagine a generic "Lua plugin" build with mlua or similar, which just plumbs through a bunch of the Helix APIs into Lua-space and provides a Lua runtime. Same could probably be achieved easily for any Rust-embeddable language but it seems like people like Lua so perhaps a small ecosystem will form around such a plugin for those who want to use it instead of Steel, without maintaining a completely separate fork :)

[getreu]

The choice of a plugin language differs form other architectural choices in the way that it defines a "user" interface. Very similar to a UI. The consumer are potential new contributes to the project. The goal should be to attract us much developers as possible who are willing to sacrifice their little free time in order to improve Helix. To lower the ease of use, the plugin language choice is crucial. Who are these potential contributors? With what languages they are familiar with? A poll would tell us more.

A side note: it seems there is only one active core developer left in the project. How to grow the active community? A lot can be learned from successful projects like Neovim. The plugin language choice is definitely an important part of the answer.

[ronisbr]

That’s precisely my point of view!

The Helix developers chose Scheme (Steel) because they want complete control over it, including embedding the virtual machine. However, the downside is that everything needs to be done in-house. For instance, if you need a library to correctly parse UTF-8 strings to create a nice plugin, you’ll probably have to code it in Steel yourself if the functionality is not exported from the editor core. Similarly, if you need a library to interface with a web service using a default API, you’ll need to code the glue code yourself.

On the other hand, if a more common plugin ecosystem were selected, you could rely on a much more robust background. Therefore, although the plugin system will allow extending the editor, I’m not convinced that we’ll see great applications like we’re seeing in Neovim.

[erasin]

Plugin system prototype for Helix #13945 .

Make Plugin with wasm/lua.

[getreu]

Complete Report: Implementation of the Plugins/Scripts Module for the Helix Editor

Develop an extensible plugin system for the Helix editor, allowing the community to add new functionalities and customize the editor through plugins based on WebAssembly (WASM) and Lua.

[getreu]

It seems, that many people are not satisfied with the official plugin system choice. Now someone comes up with an alternative solution: Lua+WASM: #13945
I wonder why this proposal is not being taken into consideration? Has anybody tested it? Or is this thread only about complaining?

[wildwestrom]

I don't know if you people are a vocal minority or not, but I for one think Lisp is the right choice for plugins.
It has damn near no syntax so it's damn easy to write and read. Why do I not just use Emacs? Because loading all the plugins I want is too slow and the APIs are so old I feel like I'm learning a new language on top of elisp.

If this gets done right, Helix will blow Emacs right out the water.

[ronisbr]

Emacs took a long time to enable compilation for speed improvements. Developing a JIT compiler is extremely challenging. Before native compilation, many aspects of Emacs designed for modern IDE use cases were extremely slow.

Steel is a relatively young interpreter (it hasn’t even reached version 1.0 and has only 39 contributors). It would take an incredibly long time for it to reach the maturity level of something like Lua. Lua, for instance, has LuaJIT, which produces remarkable performance. I have no idea how long it will take for Steel to be able to generate compiled code. Until then, any “heavy” task will be slow if implemented within a plugin in Helix.

[darshanCommits]

Until then, any “heavy” task will be slow if implemented within a plugin in Helix.

You could use rust ffi like that scooter plugin for anything like that. Plus unlike emacs, helix has alot more perf heavy features in core.

[habruening]

I understand the skepticism of the decision for Scheme. But Let me say my personal opinion. Most modern programming languages also bring a mindset and a way of thinking. You can call this a bubble or a bias. When you are in such a bubble, you can compare things, that are also in your bubble. You can say, Python fits better as an extension language than Java, because both are Object Oriented imperative languages. But you cannot compare two languages that are not in the same bubble.

The question what language is appropriate as an extension language is as legal as the question what paradigm is appropriate. Functional programming, declarative programming, procedural programming are sound alternatives to object oriented programming. I think, nobody wants to question this. The problem is, once you decide for a paradigm or a way of working, which is not mainstream, you enter a world where nothing is mainstream.

By deciding for Steel, the Helix developers did not only make a decision for a programming language. They decided for concepts. In my experience they made a good decision. But of course, this is hard to understand if you have only ever used mainstream languages. Once the decision for an approach is made, there are not many options for a language. I would also have preferred another language from that spectrum. But I think Steel is a great choice. I am more than happy with Steel, and I think, there will be enough people who are enthusiastic about Steel to keep that eco system vibrant.

I recommend everybody to buy a textbook about Scheme if you consider doing extension development. It is impossible to have an opinion about Scheme if you have not systematically learnt what Scheme is about. A few Hello World examples cannot teach you this. Before criticizing Scheme, please try to understand, why someone would like to use such an exotic language.

[snatvb]

I understand the skepticism of the decision for Scheme. But Let me say my personal opinion. Most modern programming languages also bring a mindset and a way of thinking. You can call this a bubble or a bias. When you are in such a bubble, you can compare things, that are also in your bubble. You can say, Python fits better as an extension language than Java, because both are Object Oriented imperative languages. But you cannot compare two languages that are not in the same bubble.

The question what language is appropriate as an extension language is as legal as the question what paradigm is appropriate. Functional programming, declarative programming, procedural programming are sound alternatives to object oriented programming. I think, nobody wants to question this. The problem is, once you decide for a paradigm or a way of working, which is not mainstream, you enter a world where nothing is mainstream.

By deciding for Steel, the Helix developers did not only make a decision for a programming language. They decided for concepts. In my experience they made a good decision. But of course, this is hard to understand if you have only ever used mainstream languages. Once the decision for an approach is made, there are not many options for a language. I would also have preferred another language from that spectrum. But I think Steel is a great choice. I am more than happy with Steel, and I think, there will be enough people who are enthusiastic about Steel to keep that eco system vibrant.

I recommend everybody to buy a textbook about Scheme if you consider doing extension development. It is impossible to have an opinion about Scheme if you have not systematically learnt what Scheme is about. A few Hello World examples cannot teach you this. Before criticizing Scheme, please try to understand, why someone would like to use such an exotic language.

This is not about choosing a language you like “because,” but about choosing a language that will describe the extensions.

You do this based on your needs and limitations. Your main limitation is the entry threshold. Your task is to minimize this threshold as much as possible.

Speed is also important to you—because if the extensions work slowly, then what's the point of having them at all?

Only a handful of people know this language (Steel). For example, I'm definitely not going to learn a separate language just to configure some editor. LUA is quite simple, with an extremely widespread concept similar to JavaScript (do you know how many developers use JavaScript?). It supports JIT compilation, can be called from anywhere in the program, and has proven itself to be one of the best languages for embedding.

LUA is quite widespread, from game platform scripting to machine tools and programming equipment such as mice and keyboards. It is not a dead language.

The higher the entry threshold, the fewer extensions you will have and, consequently, the less chance you will have to compete in the market. We must live not in a world of illusions, but in the real world, where there are needs and limitations.

[wildwestrom]

The higher the entry threshold, the fewer extensions you will have and, consequently, the less chance you will have to compete in the market.

You say this like they're all bad things.

[snatvb]

The higher the entry threshold, the fewer extensions you will have and, consequently, the less chance you will have to compete in the market.

You say this like they're all bad things.

do you think that product developers want their product to be less successful than their competitors' or to fail? Do you really understand how the market works?

[mdallastella]

I don't think the goal of the project is to compete in a business market (terms like "competitors", "market", suggest a business environment). Widespread adoption is nice to have, but it should not be *the* goal.

…

On 9/5/25 09:46, Andrew Avsenin wrote: do you think that product developers want their product to be less successful than their competitors' or to fail? Do you really understand how the market works?

-- Marco Dalla Stella https://marco.dallastella.name

[wildwestrom]

Is the editor created so that as few people as possible use it? A strange goal.

If using a lisp dialect means gatekeeping, then I'm all for it. Not even joking.

[snatvb]

Is the editor created so that as few people as possible use it? A strange goal.

If using a lisp dialect means gatekeeping, then I'm all for it. Not even joking.

so, then you don't understand what it editor and how to have it success 🤷‍♂️
vscode did via extensions
neovim too

Helix already has an entry threshold, but increasing it even further by reducing the number of extensions — are you really doing this editor any favors?

[wildwestrom]

This editor is opinionated and I love all its opinions.
If Helix can make them all happen then that's success in my eyes.
Go somewhere else or fork it if you don't like it.

[snatvb]

This editor is opinionated and I love all its opinions. If Helix can make them all happen then that's success in my eyes. Go somewhere else or fork it if you don't like it.

I did just that, switched to neovim

I like Helix as an idea because of its simplicity, but I found it lacking in expandability. I'm definitely not going to learn a separate language for an editor that I don't need in other situations. I already know too many programming languages

[mdallastella]

If we want to talk about real world, I can share my view and experience.

I use Emacs on a daily basis for work for about 10+ years; I program in Lisp/Clojure, so I can easily write Elisp if needed. Do I ever wrote a plugin/library for Emacs? No.
I believe the average Joe just copy and paste the plugin configuration and call it a day.

There are a lot of VSCode users. How many of them write extensions? I bet the percentage is less than 10%.

I think the same goes for NeoVim.

Helix doesn't have a plugin system at the moment, and this didn't prevent the adoption for the current user base. I think you have to be highly motivated to write your own plugin and, if you are, learning a simple (Scheme is simple) language won't stop you.

People doesn't write plugins because the plugin language is easy or largely adopted, they write plugins because they need/want them.

[rauletaveras]

I'm gonna add my two cents, as a good-faith user who loves Helix. It's my favourite piece of software. I'm here, so of course, I'm more technical than "average" people, but I'm not a dev, and I preface this to make clear where I'm coming from. On the language side, I actually love lisps and don't think Steel will be that much of an obstacle, but that's not the point of this comment.

This thread was incredibly discouraging, and the comments here do not reflect well on the health of the project. For better or worse, Helix has positioned itself as a player in the editor space and as a community project. There is no indication whatsoever this is more of a personal project that happens to be open source, or a project for a limited audience (beyond the obvious limitation of audiences who use text editors). In fact, it is this very positioning that brought me to Helix and with it to the wonderful world of actual terminal workflows and TUIs, and many others.

And Helix has almost everything it needs to be the best of the best. It has amazingly talented contributors, professionals and enthusiasts who dedicate so much of their free time to this, with high and technical standards, which is every bit what has allowed it to be the tool that it is.

In that light, the responses to the grievances expressed here have been entirely shocking. OPs comment was entirely too sarcastically worded, which is no way to invite civil debate. However, the discussion rather quickly left those original points behind and attempts at thoughtful conversation were made. Despite that, repeatedly, the attitude has been dismissive; not only dismissive, but very rudely so. And I dare say that this is bad.

It is true that Helix is open-source and everyone has the freedom to fork it, as indeed some have. It is also true people are free to choose other tools. And similarly, many other points made have complete merit: the maintainers are free to make free choices, including entirely arbitrary ones if they wanted (not what they're doing); Helix doesn't need to aim for mass adoption, it has every right to aim for a niche audience.

Where I see a problem, and please don't take this as me being entitled, is that whatever Helix's beginnings, it has grown very large. A big part of this is its many technical merits, but not only that, it does market itself (it has a very nice website and calls itself "the post-modern text-editor"), and the community markets it in its name too. This means many people use it as their daily driver, perhaps even for work. While obviously customer support is not something maintainers should aim for, I believe the community in and around Helix could be much better if there was clear communication. By this I mean, if Helix wishes to be a small, niche product, by all means. That is more than fine. But, as users, and even as developers, it would be good to know that. It means we can all make better decisions.

However, if Helix does intend to be a more significant product, something in the same arena as Neovim, then it will require community participation at all stages. Maintainers have already expressed being overwhelmed by the reviewing demands; I can only say that's a matter of course. The scale and quality of such a project is not something one, two, or three people can keep up with on their own. And if that is the desired direction, then some kinds of responses in this thread are very counterproductive; no, they are rather where community projects go to die. Helix deserves better.

Currently, I do not, and I believe the broader community doesn't either, know where Helix is going or what the thought process is. Many of us would be more than happy to do everything to support the vision: it has made an amazing piece of software. But for that, knowing what the vision is is necessary. Similarly, the kind of complaint that spawned this thread will likely continue, if not for Steel plugins then for some other issue, simply because it is not clear whether Helix will be a good fit for someone in particular. Those for whom a given issue is a deal breaker would know to walk away or fork immediately or whatever, saving everyone's time and emotional energy.

As for myself, I love the project dearly, and I am learning Rust if only so I can understand it better. However, if it intends to be a community project, and if some attitudes expressed in this thread continue, then I know it's only a matter of time before it's unusable. I would like to not keep putting my eggs in that basket only for it to collapse under it. Not, again, that I'm owed anything by anyone here: that's my problem, and I'm insignificant to this whole thing.

Thank you kindly for your time. I appreciate you all.