-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Steel as an optional plugin system #8675
base: master
Are you sure you want to change the base?
Conversation
Hi @mattwparas and great work btw. I've tested this PR on Windows and it worked as expected. (Windows, no WSL, and a sprinkle of MSYS2 for some binaries. Not sure if MSYS2 was relevant) I tested it prior to your recent documentation updates, so I had to compare your dotfiles to the examples and get close tk what you had and it worked 💪 |
Add editor-switch-action! command to be able to switch to an existing buffer
|
This is something that will come with some more changes to the configuration system (and as a result, I don't have a perfect fix), but in the mean time, this should help force a reload of the relevant parts of the init when you call config-open: (require (prefix-in helix.static. "helix/static.scm"))
;; Define a function for your keybindings
(define (setup-keybindings)
(define scm-keybindings (hash "insert" (hash "ret" ':scheme-indent "C-l" ':insert-lambda)))
;; Grab whatever the existing keybinding map is
(define standard-keybindings (deep-copy-global-keybindings))
;; File tree stuff
(define file-tree-base (deep-copy-global-keybindings))
(add-global-keybinding (hash "normal" (hash "C-r" (hash "f" ":recentf-open-files"))))
(merge-keybindings standard-keybindings scm-keybindings)
(merge-keybindings file-tree-base FILE-TREE-KEYBINDINGS)
(set-global-buffer-or-extension-keymap (hash "scm" standard-keybindings FILE-TREE file-tree-base)))
;;;;;;;;;;;;;;;;;;;;;;;;;; Options ;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Define a function for your options
(define (configure-options)
(file-picker (fp-hidden #f))
(cursorline #t)
(soft-wrap (sw-enable #t)))
;; New config reload, shadows the old one so it should have the things set up
(define (config-reload)
(helix.config-reload)
(configure-options)
(setup-keybindings))
;; Otherwise, before the init file is done, setup things like usual
(setup-keybindings)
(configure-options)
|
Thanks but it seems that I can't override (define (main)
(helix.theme "everblush")
; keymap
)
(define (crl)
(helix.config-reload)
(main)) Now I can use |
Yeah so not sure how I didn't run into this, maybe I'm running a build that is slightly different, but it has an event queue for configuration updates that won't get processed until after the steel script exits, so I should have seen this coming 😅 Your solution with the 0 ms delay callback, as ugly as it is, should get the job done, since it'll first process the config-reload event, followed by applying the modifications to the resulting config object in a callback. I believe the resulting configuration changes that I mentioned before should fix this whole process |
What is left to be done here? Also, are you looking for contributions and if so, what can I do to be helpful? |
Hi, great project! I noticed an issue with the implementation of (define (shell . args)
(define expanded (map (lambda (x) (if (equal? x "%") (current-path) x)) args))
(helix.run-shell-command expanded) ;; should be changed to (apply helix.run-shell-command expanded)
) |
I have to address some lingering comments and otherwise clean up the code, then work on integrating the upcoming configuration system changes. If you're particularly interested in contributing, the best thing you can do at this point is to use this branch and report issues, or alternatively, fix those issues and open a PR against this branch. I wouldn't necessarily recommend committing to adding new features to this unless its plainly obvious those features should be available, i.e. the lack of them now appears to be an oversight. I think the first iteration of the plugin system might be a trimmed down version of this branch since I've done quite a bit of hacking on exposing APIs that might not get added in the first go, or need further thought in order to hone the exact API that does get exposed. For example, the work that I've done with the component API hasn't even really been reviewed yet; this will probably need some love before it gets merged, but the configuration part will most likely be more straightforward. |
Good catch, I'll push a fix for this |
@mattwparas hi, i have problem with ur config open-term/xplr |
I don't know if this is the place for this discussion, but I managed to install this version of helix and I wanna build a plugin. I want to either make a "git blame" or "copilot suggestion" plugin - but both of them make use of some kind of ghost text and I've tried searching for it but cannot find a way to make ghost text. I'm not sure if this is possible in this plugin-system today, or would it require some more capabilities provided from helix? |
I'm a broken record: |
AFAICT It does not expose such an API. I think the plan is to get a minimal version that can replace the config out and then add on to it w/ subsequent PRs to reduce the collective effort. |
Notes:
Opening this just to track progress on the effort and gather some feedback. There is still work to be done but I would like to gather some opinions on the direction before I continue more.
You can see my currently functioning helix config here and there are instructions listed in the
STEEL.md
file. The main repo for steel lives here, however much documentation is in works and will be added soon.The bulk of the implementation lies in the
engine.rs
andscheme.rs
files.Design
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.
The interface I ended up with (which is subject to change and would love feedback on) is the following:
If you can implement this, the engine should be able to be embedded within Helix. 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.
As a result, Steel here is entirely optional and also remains completely backwards compatible with the existing toml configuration. Steel is just another layer on the existing configuration chain, and as such will be applied last. This applies to both the
config.toml
and thelanguages.toml
. Keybindings can be defined via Steel as well, and these can be buffer specific, language specific, or global. Themes can also be defined from Steel code and enabled, although this is not as rigorously tested and is a relatively recent addition. Otherwise, I have been using this as my daily driver to develop for the last few months.I opted for a two tiered approach, centered around a handful of design ideas that I'd like feedback on:
The first, there is a
init.scm
and ahelix.scm
file - thehelix.scm
module is where you define any commands that you would like to use at all. Any function exposed via that module is eligible to be used as a typed command or via a keybinding. For example:This would then make the command
:shell
available, and it will just replace the%
with the current file. The documentation listed in the@doc
doc comment will also pop up explaining what the command does:Once the
helix.scm
module isrequire
'd - then theinit.scm
file is run. One thing to note is that thehelix.scm
module does not have direct access to a running helix context. It must act entirely stateless of anything related to the helix context object. Runninginit.scm
gives access to a helix object, currently defined as*helix.cx*
. This is something I'm not sure I particularly love, as it makes async function calls a bit odd - I think it might make more sense to make the helix context just a global inside of a module. This would also save the hassle that every function exposed has to accept acx
parameter - this ends up with a great deal of boilerplate that I don't love. Consider the following:Every function call to helix built ins requires passing in the
cx
object - I think just having them be able to reference the global behind the scenes would make this a bit ergonomic. The integration with the helix runtime would make sure whether that variable actually points to a legal context, since we pass this in via reference, so it is only alive for the duration of the call to the engine.Async functions
Steel has support for async functions, and has successfully been integrated with the tokio runtime used within helix, however it requires constructing manually the callback function yourself, rather than elegantly being able to use something like
await
. More to come on this, since the eventual design will depend on the decision to use a local context variable vs a global one.Built in functions
The basic built in functions are first all of the function that are typed and static - i.e. everything here:
However, these functions don't return values so aren't particularly useful for anything but their side effects to the editor state. As a result, I've taken the liberty of defining functions as I've needed/wanted them. Some care will need to be decided what those functions actually exposed are.
Examples
Here are some examples of plugins that I have developed using Steel:
File tree
Source can be found here
filetree.webm
Recent file picker
Source can be found here
recent-files.webm
This persists your recent files between sessions.
Scheme indent
Since steel is a scheme, there is a relatively okay scheme indent mode that only applied on
.scm
files, which can be found here. The implementation requires a little love, but worked enough for me to use helix to write scheme code 😄Terminal emulator
I did manage to whip up a terminal emulator, however paused the development of it while focusing on other things. When I get it back into working shape, I will post a video of it here. I am not sure what the status is with respect to a built in terminal emulator, but the one I got working did not attempt to do complete emulation, but rather just maintained a shell to interact with non-interactively (e.g. don't try to launch helix in it, you'll have a bad time 😄 )
Steel as a choice for a language
I understand that there is skepticism around something like Steel, however I have been working diligently on improving it. My current projects include shoring up the documentation, and working on an LSP for it to make development easier - but I will do that in parallel with maintaining this PR. 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 behavior that I've outlined here.
Pure rust plugins
As part of this, I spent some time trying to expose a C ABI from helix to do rust to rust plugins directly in helix without a scripting engine, with little success. Steel supports loading dylibs over a stable abi (will link to documentation once I've written it). I used this to develop the proof of concept terminal emulator. So, you might not be a huge fan of scheme code, but in theory you can write mostly Rust and use Steel as glue if you'd like - you would just be limited to the abi compatible types.
System compatibility
I develop off of Linux and Mac - but have not tested on windows. I have access to a windows system, and will get around to testing on that when the time comes.