@d12bb I added it, but this list is not all that useful, as it includes things that are outdated from the conversation. Nevertheless, I'm happy to keep it up-to-date.

Is there any reason not to go down the Lua path?

I'm not personally a fan of Lua after using it with Neovim for a while, although it is much better than VimScript 😉 That being said, picking Lua would ease the switch from Neovim to Helix for some users.

I like the idea of using a small embedded lisp.

vonuvoli Scheme is another plugin language option.

Another +1 forLua (and I'm also coming from Neovim :-) ). I don't really likeLua as a programming language however I absolutely do love it as a "runtime". And there are a ton of transpilers for it, I for one really loveFennel (all my neovim config is inFennel and I wrote several plugins inFennel as well).

With that combo you get the best of both worlds: a lisp-like language with the batteries of Lua. I just kept looking for excuses to write more and more Fennel code :-) That was a lot of fun...

With Lua you'd not just make it easier for some Neovim users to come over, you'd also make it easier for plugin authors to port their work over.

@d12bb afaik guile is not available on windows, so how would that work?

Rhai is too new and has a bus factor of one. If the maintainer stops maintaining it or it turns out we need certain features or bugfixes then we're stuck.

I think he is just younger and isnt necessarily aware of the fact that there are probably hundreds of people subscribed to this thread receiving an email on every comment.
Give it time and someone passionate can make a great project that the community will depend on.

@LeoniePhiline the energy you have is great, but the maintainers here have to work on this on their free time and they are streched quite thin. Theyve invested countless hours into this and they will have to suffer the consequences of the decision they make. Be careful when you post a comment as this could be badly intererpreted. Someone here could become a co contributor on a project you make later or it could become something you wish you didnt say and cant take back. You likely have a bright future ahead, careful on the way there!

@archseer@pascalkuthe thanks a lot for the work and patience you put on this project. For every little thing that is annoying, there are probably hundreds of people who are very grateful. There is so much work left to do, but so much has been done already ! Keep up the good work, im really looking forward to what helix brings up next !

Honestly I don't really like the idea of Lisp, and I have no control over what the creators think, because they are the creators for a reason, but I would give a suggestion that I doubt they would accept or even see: Ruby.

Again, ruby is not widely used and I doubt they will implement it. It was just a suggestion that doesn't really add much.

I agree on choosing lisp over wasm might be why there doesnt seem to be plugins as of end of July 2023. It seems wasm would be a perfect solution to allow a larger plugin ecosystem and more development, Far more people on the planet could use a wasm interface over a lisp interface.

might be why there doesnt seem to be plugins as of end of July 2023

Or perhaps it's because we had three separate attempts at integrating WASM that didn't lead anywhere? :)

Integrating WASM isn't just a hundred lines of code either, and the lack of a standard ABI interface means we'd still be targetting something on WASM rather than WASM. e.g. if weintegrate Guile via WASM, that's a WASM interface, but I'm pretty sure it's not the one you were thinking of! (or a more serious example,quill only targets rust so far)

I posted above, but would it be worth examining the wasm 2.0 announcement from a few days ago? Or was this included in your assessment.

Although, I do get the main point about wasm just being way too unstable to get any real progress done

It would be useful. A few plugin ideas can be foundin the issue tracker with theA-plugin label (some closed issues are interesting as well, some are simply converted to discussions)

This is what I was suggesting inthis comment. For me,magit is unparalleled as a git tool, and I'd love to see integration that tight in helix. Perhaps in core. It is discussed in#227.

Now we should think about the best way to do it. To me I thought we should first create an overloaded list and then put it in a poll because I think we can't edit polls to add new plugins(or plugin ideas) later. If we can then it's a nice thing. But since we probably cannot, this should have it's own place on the helix website where a plugin idea could be added to the list on user suggestions. I can full help to maintain such page. If authorization is an issue then I'll create a repo right away where I will add user suggested plugins as they suggest me in chats, discussions or issues.

Some of you guys might be concerned about my recent disrespectful behavior at element, for which I apologize again. I'll try to stay absolutely neutral with that page and put my full efforts in maintaining that page if you guys help me fix marksman for markdown in helix first ; )

This could be useful to kind of get a clearer picture of what features the community and maintainers would like to be part of the core experience vs what belongs as a community maintained plug-in.

But as for what to work on, I think once a plug-in system lands, this will largely be determined by the developers who put the effort into it. Devs will naturally pick the features that best motivate them. And what the most popular plugins will end up being determined naturally I think.

Here is the list:https://github.com/zim0369/helix_plugins

I personally quite like the idea of rust-only WASM and we could definitely overcome the WASM limitations in that case but I am not sure if the maintainers are open to that.
It also doesn't address the specific use-case I have in mind:
I have implemented git integration based on gitoxide in#3890 and would love to also support other VCS (like pejul or mecurial) aswell.
The implementation is already completely decoupled and everything git specific could be trivially moved to a plugin.
Other VCS could be trivially implemented in the same way.
However VCS are very performance sensitive and rely heavily on memmap and other mechanisms that are not possible in WASM.
So moving the VCS integration to plugins requires native plugins.

Another example where native plugins are required is FFI.
There are some things which are simply too hard to reimplement from scratch and linking to an existing C implementation (which definitely doesn't compile to WASM) is simply easier (example hunspell for spellchecking).

Furthermore WASM needs to be compiled anyway.
While people could write WASM by hand, in practice, nobody does that.
So people will download precompiled WASM instead of the source-code anyway.
In that case its not that far of a stretch to download a precompiled dynamic lib (so compilation would be done by the plugin developer not by the user).
Yes the lib is platform specific but its honestly not that hard to just enforce a naming scheme like "-.hplugin" for example and then just let helix determine the correct URL automatically.

I do agree that WASM is a nicer solution than native in cases where native is not required . That's why I would like to see both options (with perhaps only a trusted few plugins available as native plugins like VCS integration) and native as an easier first step.

I personally quite like the idea of rust-only WASM and we could definitely overcome the WASM limitations in that case but I am not sure if the maintainers are open to that. It also doesn't address the specific use-case I have in mind: I have implemented git integration based on gitoxide in#3890 and would love to also support other VCS (like pejul or mecurial) aswell. The implementation is already completely decoupled and everything git specific could be trivially moved to a plugin. Other VCS could be trivially implemented in the same way. However VCS are very performance sensitive and rely heavily on memmap and other mechanisms that are not possible in WASM. So moving the VCS integration to plugins requires native plugins.

I have to agree with that, as a 'rust-only' approach completely eliminates the benefit wasm as a plugin system gives you.
Also; it would be not in any way better than just exposing a Rust api / just using a scripting language in general.

edit: in all this time using Emacs which crashes, blocks, races too much mainly when using third-party packages/extensions, I can say I prefer rust safety and thus a rust-only wasm over lisp/scheme. I agree with@pascalkuthe

Rust a compiled language; that means no iterative/REPL-driven, easy, fast development as allowed by something like lisp/scheme, which for me is a big plus for extending the system (imagine just if Helix ever implements a much needed for serious useproper client-server architecture, I want this thing uptime 24/7, we need this to be dynamic). Y'all should look into GNU Emacs and its incredible approach (C for underlying software, and Lisp for extending it). A major issue with it is the language in that people really want to make Emacs their total computing environment, so they want to access amodern Web browser on it and so on, which only ecosystems like javascript, python have libraries for

• https://github.com/emacs-eaf/emacs-application-framework (python)
• https://github.com/emacs-ng/emacs-ng (javascript)

also it is a big issue that in GNU Emacs Elisp is actually a bad language for today's concurrent computing world. So a language like Rust, would shine in providing a safe tooling, because at least for Emacs, at least 50% of its value comes from its ecosystem (packages/extensions).

Rust a compiled language; that means no iterative/REPL-driven, easy, fast development as allowed by something like lisp/scheme, which for me is a big plus for extending the system

For me the reason I want to implement extensions in Rust is precisely the opposite. REPL driven development look appealing at first but honestly I much prefer the reliability and speed that rust provides over dynamic languages. My experience with dynamically typed languages (python, lisp variants, lua, ...) is that you end up with a ton of bugs that a static type system would prevent unless you use copious amounts of testing (which lets be honest most people won't do for an editor plugin).

(imagine just if Helix ever implements a much needed for serious use#312 (comment), I want this thing uptime 24/7, we need this to be dynamic

Both shared libraries and WASM can be loaded and unloaded at runtime so that would not be a problem.

Y'all should look into GNU Emacs and its incredible approach (C for underlying software, and Lisp for extending it).

I think most people here are familiar with emacs. Both Emacs and vim both useC + extension language approach because at their inception no better approach was around. C/C++ were the only mainstream options for high performance code but writing anything in those languages is super tedious. Modern compiled languages (likerust andgo) solve this problem by offering high speed, static typingand high productivity. I can definitely see a place for alisp (or whatever other dynamic language) being available for configuration and simple user scripting. In fact I specifically mentioned that my approach as a basis for such a system in the future.

However I would hope that for complex plugins, that we are able to leverage existing statically typed programming languages to ensure that helix plugins can be just as reliable as the helix core code

@pascalkuthe

However I would hope that for complex plugins, that we are able to leverage existing statically typed programming languages to ensure that helix plugins can be just as reliable as the helix core code

similar to the implementation of theabi-stable

abi_stable promotes itself doing "load-time type-checking".

For Rust-to-Rust ffi, with a focus on creating libraries loaded at program startup, and with load-time type-checking.

Does this imply additional memory safety guarantees compared to a C ABI interface?

You mention JSON API as an option and that it would be slow to convert JSON constant for message processing. What about a binary protocol? The plugins could be applications started by Helix that meet some binary protocol specification on a unix domain socket. Do we think there are interactions that plugins would want that are orders of magnitude more chatty than LSP, which uses a similar approach (and JSON)?

I just think it's interesting from a feature isolation standpoint. If a plugin crashes, my editor doesn't freeze or crash (assuming it handles timeouts and read delays with grace).

For the sake of completeness, I am adding picolisp here. Its extremely small and has a very powerful ffi and can interact with everything. Without knowing much I suspect it would be very easy to embed.

Looks likeyears is the right answer.

If only we used Cloud Build! Then we'd be up and running in a weekend.

true

100%

...#3806 (comment)

Well, you could always go the Suckless way and write patches to apply after pulling, before compiling. No support from Helix itself needed, but you would obviously have to keep up with internal code changes (but that would be the case with modules in .config too)

This could be a great short-term solution. Xmonad, a window manager written in Haskell, uses essentially this model. The ~/.xmonad config file imports xmonad as a library, and configures it using Haskell, before running it. Thexmonad command is a wrapper that checks for changes in~/.xmonad, compiles it to a binary, and runs the binary.

This would get something working right away, and wouldn't require a different language or a VM.

https://github.com/bytecodealliance/wasmtime/releases/tag/v2.0.0 and now there's 2.0

https://github.com/bytecodealliance/wasmtime/releases/tag/v2.0.0 and now there's 2.0

They jumped a whole version number between September and now?? How did that happen? 😅

The release process is describedhere.

Sorry for coming across a bit harsh, I really really love Helix and its vision, thanks for all your hard work!

Find ways to makeHelix possible. If you don't know how, make sure that you arenot standing in the way.

As an ordinary user, in this comment, i just want to

1. Try help cool the plugin-anxiety in the community.
2. Recap a little on what I think is going on in the editor evolution space
3. Convince reader why there is no hurry and why just using any other modal editor for now, until helix is ready, even if that say is 2 years from now.

1: I am guessing the comment-OP, and other people like me, who want plugins are not a plugin developer, but a plugin user. Possibility of great plugin system is not the only lure of helix. I want to herein convince reader that its present unavailability of plugin-system is an insignificant negative.
Comment-OP's main intent is to learn a modal editor and its scripting language, but assumes that learning how to use either is a big hurdle, and so wants to make a one-time decision. Perhaps comment-OP assumes it will be difficult to switch later and fears that one will be stuck with a current decision.
First, let's recap some reasons:
The main advantage of terminal editors is that they are not restricted to desktop usage. (However, increased network speeds now allow gui-editors to do fast remote-fs as well as direct network editing/remote-development. )
The main reason for terminal editors like vim and emacs, is to do featureful-editing (unlike pico) in a terminal.
The main reason for learning a key-stroke terminal editor is because, as keystrokes get committed to muscle memory.
The main advantage of vi/vim/neovim over emacs, is that vim-style modal editing avoids using the ctrl-key, which is suitable for remote-ttys and tty-multiplexers. (with due respect, emacs has other advantages, pls noone wants to enter this editor-war).
The main advantage of modal editor is that it separates of edit-mode and command-mode and allows for a style of keystrokes.
The main advantage of minimal-vi modal editor is that it can be packaged onto a lightweight minimal system. like an initrd or embedded system.
The reason for kakoune is that for its new selection-first key-bindings, allowing for visual operation.
The reason for helix is that it uses kakoune's key-bindings and visual-selection-feature, and is implemented in rust, which is thought to be blazing fast, has modern libraries (crates), and promotes faster development with lesser bugs.

When one chooses an editor, one wants to use the same editor everywhere as possible, to get best use of muscle memory.
Learning to use one modal editor is not as big a task, and is also a 1-time task. Switching to another one, when a newly developed editor (such as kakoune or helix) matures is not as big a task as one might think. Once, one is sure that the new editor fits all your use-cases, a switch at a later time is easy to do.
First, If one's intention was to make a contribution to helix as a plugin developer/contributor, I see your point why one is in a hurry, can't argue there. But, if one just want to use plugins, then one is better off with neovim/vim. which already have mature plugins, and for now, just watch how helix develops.
The vim/emacs documentation is large. and one might be tempted to think one will need to invest a lot of time learning. But in reality, one uses only a small table-ful of commands that often fit on a 1-page-pdf-cheatsheat. Even as a seasoned user, one never rarely if ever needs to use all of the editors features. The human mind cannot remember rarely used features. When one encounters a situation needing one, for one time-use its often expedient just to manually-repeat. One only takes the time to lookup the advanced tricks, only when one finds oneself doing manual-repeating-work more frequently.
If and when you choose to switch, one will in short order of time, learn to forget the muscle-memory keybindings of vi/vim/neovim and learn that of kakoune/helix. When plugin-system and plugins are ready, Switching rc-scripts, custom defaults and plugin customization-s, are one time tasks, and will be least of the problems. Once, you get your scripts to work the way you want, one seldom sees them again, so one forgets and there is re-learning each time one dabbles into it. Its not like one knows/remembers vimscript the same way one knows/learns/remembers bash/pwsh/python/C++/etc.
tbh, I anticipate one may never fully let go of vi and its key-bindings, its too ubiquitous, one will run into it as default editor in many systems, and one will find oneself in situations requiring its use, even after switching to say helix.

2: editor evolution
Original vi was proprietary unix but very bare-bones.
vim is written in C, had more features, was much more usable and is open-source.
neovim brought a different, but more modern codebase/architecture, that was more conducive to faster community development, supported LSP and lua-engine.
Xi editor, no longer developed, introduced a concept called the rope-data-structure for large files.
kakoune is written in C++, but departs from vim's verb-first keybinding to selection-first keybinding.
tree-sitter was a new parsing idea that improved how syntax was highlighted.
helix is a rust implementation using tree-sitter and the kakoune-style key-bindings.
anyone wants to add here?

3: no hurry
So as mentioned in point 1. it will be easy to switch when the time comes.
For now, one can just watch how helix develops for now, try it occasionally and use neovim/something-else for most purposes.
Its more important to make good design and implementation decisions in well thought way, than in a hurry, pass the tests of time, and not end up in editor graveyard like Xi.
So let developers who are thinking and contributing their free time, take their time to make the best decisions under the circumstances.
It will not be that difficult to make a switch, if and when helix is ready.

I think the charm with Helix is that it just works from the box, and I don't need to spend time fixing .init files like with Neovim. So the more we could put in as default behavior in hx without making it bloated, the better. For example, if we had a nice way to just call command line tools and get the output into a temporary shown buffer, maybe even in structured format (similar to nushell or jc), that would work fine for me. Then I could write various custom shell scripts and use those in my environment not putting a burden on custom plugins and a plugin runtime.

Git integration could/ should be part of the default hx editor, for example.

if we had a nice way to just call command line tools and get the output into a temporary shown buffer

Link tohttps://github.com/fregante/GhostText/blob/main/PROTOCOL.md an#3478

While I do think a fully fleshed out plugin system is a fine idea, I also love how much works immediately upon installation,@ksandvik. In fact, think it is probably a good design goal, even if not stated, to have a robust, usable, and feature-rich editing experience out-of-the-box, and reserve plugins for unique or resource intense components.

I am excited to see where all this lands and am so pleased that the editor is a perfectly capable joy to use in the meantime.

Nice !
Can't stress enough how important a sandboxing/permission system would be for editor plugins, this seems like a good way towards that goal !

In adiscussion below, it seemed like sandboxing, in some implementations, may force byte-array ser-de for call arguments and return values across host-guest interface. It may be that ser-de does not affect performance if if such funtion-calls into host are rare.

The general vibe I got while reading all comments is there are those who are enthusiastic about sandboxing, and wasm being a web technology has a selling point of easy to sandbox.

But, is Sandboxing necessary?

Sandboxing

• implies memory isolation
• prevents unintentional or malicious access to something that not asked for.
• allows for a permissioning system.
• wiki

Sandboxing is important in use-cases like

• browsers, where privacy and security needs are very high
• mobile phone apps, where every business entity wants user to install an app, but shouldn't do more than what a user allows
• virtual-machines/emulators, where a guest system should not access any host resources
• interception and firewalling apps, where one wants to monitor or control over what a guest requests.

Editors and IDEs are usually trusted applications that pretty much have access to anything. Users are also economic with plugin choices and they are also trusted, ergo the question: So what if editor plugins do too? Does sandboxing make sense for editor plugins?

For completeness of discussion sake, could one try expand on all the future reasons/use-cases sand-boxing brings to editor plugins. Perhaps also list some known cases in other projects where lack of sandboxing caused difficulties. (just trying to learn here)

Some reasons I could think of

• permission granularity, just because the main-prog requests location-access, one shouldn't assume all plugins should automatically get location-access
• one day if there is a need to port to a system/platform that disallows native calls
• one day if there is a need to port into a browser/webapp which forces sandboxing by design.
• one day if something super virus/malicious untrusted plugin comes along

The above to me seem far fetched and don't feel compelling enough to want them in editor plugins.

I am also using gitui (similar to tig) for that but to me there is value in having it right in the editor. The context switch of having to look at a seperate window to figure out what changed, read the line number and to type that into the editor feels much more cumbersome then just pressing a keybinding in my editor or using a picker (yes you can technically edit in tic/gitui but I much prefer to keep my editing in helix, especially for complex changes).

tig does not work the same way asgitui (andlazygit). And, if I may editorialize for a minute, I considergutui /lazygit to be bad TUIs for this reason. There's a historical precedent of delegating text editing tasks from a TUI to your$EDITOR variable. In fact, historically that's been one of the value-adds of using TUI software: One consistent editing environment regardless of task. So you'd have a dedicate interface for browsing email message (e.g.,mutt), but when you're actually editing text, you used your$EDITOR (e.g.,vim). Somutt opensvim with the appropriate content (e.g., message being replied to). When you read historical documents on Unix, this is just an assumption of how things work, so I always find it odd these lessons seems to have been lost in the sands of time (GitHub'sgh tool is another example of a TUI I find unusable for this reason).

tig follows this pattern correctly: Just hit enter on a diff intig and your brought to the exact line number of the changein your$EDITOR (seeeditor-line-number (bool) inman tigrc note this doesn't work-out-of-the-box yet with Helix,so I made a little wrapper for myself to support it). Quit your editor and your brought right back to thetig interface where you left off. This works so well, I actually find it's actually, somewhat unintuitively, more efficient than integrated VCS in a text editor / IDE. This is because the key binding space is so exhausted in text editors / IDEs that adding navigating diffs to an editor is usually more keystrokes than just delegating that task totig.

With that said, Ido think dedicated VSC integration could be better thantig if it's done correctly. And I think you're diff is the right approach! I think it would have to be in the form of updates to Helix core, and it should use a built-in key-binding system that allows navigating and operating on hunks efficiently, while co-existing nicely with Helix's other key bindings).

Supporting a workflow like that is exactly my long term goal. Getting a vimdiff like functionality is a bit more complicated because it requires virtual text (but we are also working towards making that happen in the future) but setting the commit for comparison should be fairly easy to do and with the gutter/jumping to the change (and potentially a picker for diffs) is already quite useful

❤️❤️❤️!

I think that Helix really does need a plugin/extension API. There some languages such as Idris and Clojure that are really meant to be written in an interactive manner, and unless it is possible to write extensions to support these languages, Helix will fundamentally lack support for them in a way that no other popular editor does. LSP is delightful, but neither it nor any other protocol will ever be able to support specialized, language-specific needs such as these interactive editing modes.

As more developer tools companies begin introducing VSCode extensions along with their products, as well as some popular libraries used for development, this sentiment can only go so far.

Given that Helix decides to not go with a plugin system at all, these new products will have no way of integrating themselves into the editor. Let's consider this: if Vim adopted LSP when it came out, would NeoVim have ever taken off? Would there need to be this whole effort to "port" LSP into Vim just to get it on-par with VSCode?CoC.vim is basically a fully-fledged JavaScript workspace in your Vim, including stuff like package management and configuration abilities, and this isjust to get VSCode plugins working, because Vim itself (well, at least earlier versions) has/had absolutely no way of supporting this kind of functionality.

So, I would say that if Helixdoesn't build a plugin system, then we are digging our own grave here, IMO. That said, I don't think it needs to be all that crazy. As others have said in this discussion, most editor plugins these days really don't need much: call a CLI tool of some kind, read its response and massage it into the data the editor needs to show feedback. Not really that complicated, not sure if we need an enterprise-scale common runtime system just for that. LSP and code formatters are really good enough for my needs, personally.

call a CLI tool of some kind, read its response and massage it into the data the editor needs to show feedback. Not really that complicated, not sure if we need an enterprise-scale common runtime system just for that

This is exactly what kakoune does, and it doesn't scale well even to simple use cases. All the shelling out is extremely expensive and makes using even a few plugins at the same time extremely sluggish.

Writing a shell script is not a deal breaker, but having to write a shell script in a string literal in a kakoune script was a deal breaker. There is no good way to indent shell script in a string literal in a kakoune script. There is no good way to activate syntax highlighting and automatic indentation for blocks of external programming languages in a kakoune script.

Thus, kakoune sucks at scripting. It doesn't have a clean way to deal with external languages. Because kakoune script doesn't have control structures like if statement, it has to embed shell script in a string literal. It is a failed attempt at an orthogonal plugin system.

It's also difficult to keep IPC(interprocess communication) fast. Making IPC fast is possible, but it requires a careful design and optimization.

I think lua as the official plugin language is a good starting point, but the real deal would be to have one official scripting/plugin language that is run by an interpreter running on sandboxed webassembly runtime. Helix can include the interpreter. Users can configure helix with the official scripting language running on a webassembly interpreter. Then, you would have orthogonality through other compiled webassembly languages. We just need to wait for a good webassembly interpreter.

Let's not lol.

Using a local Python interpreter would introduce all sorts of problem like you already mentioned. No I don't want to set up virtual Python environment just for using some plugins... I need things tojust work like they do in say VS Code.

What about shipping an interpreter likeRustPython? I think that's too much. It increases Helix compile time by a lot and it's likely not very portable.

Actually, same energy as:#3806 (comment)

Hmm fair points. But I guess the purpose of plugins should be that it's easy to author, and it's pluggable and it's optional to the core experience. Hence a scripting language is often more successful.

Agree that RustPython is probably overkill (although TBF I don't really know how big it is, nor the compile time).

Throwing ideas out there, how about somehow limiting people to core python3? I don't know enough to comment whether core python would suffice for writing plugins. Cursorily looks like what neovimdoes for Lua? Although it seems to ship the Lua interpreter.

And also is it a reasonable assumption/pre-requisite to make sure people have Python 3.7+ installed on their machines (my initial thoughts are it is, because most distros ship with Python, excluding windows).

I don't think shipping only core will suffice because some plugins like discord presence may need more more than that

I think you meant to reply to a thread above, but anyways:

IMO:

No plugins but features well integrated ≈ Contained and sandboxed plugin system (wasm) >>> Any other plugin solution

@archseer

This now requires us to set up and maintain custom build infrastructure

You already have one.

(not to mention we need to compile per architecture).

You already do that.

You're also implicitly trusting binary blobs from some server that has to be properly secured (and if the server ever gets hacked it would be very easy to deliver malicious payloads to end users).

You’ve got the same issue right now with offering precompiled binaries in thegithub releases.

Nothing changes. It’s just the same CI with an added parameter (list of plugins).

Tamper-proofing is a solved issue. It is common practice to even distribute binaries through third party mirrors as long as the checksums are published by the primary source.

@pascalkuthe

Creating a plugin API in rust is still needed.
So you need a fixed and versioned API and despite some confusion from some people in this thread that's not that hard to implement with the C ABI and then you can just dynanically load the plugins at runtime.

Of course you need a versioned API! Any possible solution (including lisp) needs a versioned API.

Now imagine you could do all that without the need for unsafe external C bridges, in plain safe rust.

see the selected answer to this thread

The selected answer is outdated; mentioning wasm, an idea which is said to have been discarded.

Exactly like what I propose, the selected answer mentions rust-based plugins for performance. You writing "It doesn't really solve anything either" is just rude. It does in fact solve the problem of using rust-based pluginswhile not relying on wasm, and neither on people having to have a rust toolchain ready.

But this doesn't solve the primary usecase for the plugin system: A more powerful scriptable config. Which can only be covered by a scripting language (lisp)

The primary use case for any plugin system isextensible functionality. No scriptable config.

A more powerful scriptable config can only ever be secondary.

A scriptable config is aseparate issue that should receive aseparate solution. That’s aconfig problem, not aneditor functionality problem.

It would help seeing those two realms more clearly as separated.

If you will, a scriptable config system could be implemented as one of many native rust plugins.

The use case for any plugin system is extensible functionality.

The use case of anyplugin system is that you canplug components in.

What you're proposing right now is something where, if I wanted to add a new plugin to test it/see if I like it, I'd need to go to a configurator page, to tick all the boxes I had beforeplus one, and then wait for a CI process to run and build the editor, and then download it.

And do that foreach architecture if I use helix on a macbook and a linux desktop for example.

I really don't like that UX for a plugin system.

This is absolutely acceptable if you can haveboth safe andand fast plugins.

Choose C bindings and youwill have unsafe pointer handling, memory leaks, segfaults, and vulnerability hell in the plugin system.

Choose a scripting language (for the plugin functionality, not the configuration, mind you) and you get a soggy laggy editor that calls into foreign scripting runtimes on each keystroke.

What you're proposing right now is something where, if I wanted to add a new plugin to test it/see if I like it, I'd need to go to a configurator page, to tick all the boxes I had before plus one, and then wait for a CI process to run and build the editor, and then download it.
And do that for each architecture if I use helix on a macbook and a linux desktop for example.

Web app:

In a web app, this is easily solved with a cookies / local storage. You will never need to tick boxes for plugins you already have installed - this is a typical task computers are supposed to do for us.

CLI app:

If you have the Cloud Build system API client implemented as CLI tool instead of web app, then it already knows which plugins you use, and it can just add the one you like to try. Same if plugin management was integrated into helix itself. (Just runhx plugin add <plugin-name>.)

Build time:

If you are not running plugins nobody else uses, then your binaries will already have been built and cached, so there is no waiting time at all. You get your binary directly and can start trying the plugin.

On the other hand, if you are experimenting with your own plugin or something new and unknown, then you would need to compile it anyway.

Except if, as said above, the plugin system is based on slow scripting runtimes which would make you quit using helix anyway, due to bad runtime UX.

The image you are painting is unrealistic: You are not changing your set of plugins constantly. Plugging something in does not mean that you rip it back out and shove it in again multiple times a day. It just means composability and extensibility. It means being able to make a connection, an integration happen.

If you require a dynamic system, use something written in a dynamic language, or something static with a stable ABI which is also safe (hint: does not exist).

Go with C bindings

Now imagine you could do all that without the need for unsafe external C bridges, in plain safe rust.

Ironically, Rust does not have a stable ABI so we'd have to compile to C ABI.