| ▲ | ta8645 21 hours ago |
| > All I want is ... Understandable, for sure, but the number of users who want their own "simple" addition means it gets overwhelming pretty quickly. Helix has deferred work on most extra functionality until after implementing a Scheme extension language. Once that's done, adding features might be as simple as installing a plugin. |
|
| ▲ | agumonkey 21 hours ago | parent | next [-] |
| Wait, helix will get scheme before gnu emacs, aww |
|
| ▲ | 0cf8612b2e1e 21 hours ago | parent | prev [-] |
| Authors are free to do as they please, but as an entitled member of the peanut gallery…aren’t there already enough small configuration languages? Seems like a distraction when there are already hundreds of schemes, Lua, Janet, etc. |
| |
| ▲ | mananaysiempre 21 hours ago | parent | next [-] | | In that case, Kakoune[1] (Helix’s main inspiration) is probably more your jam. You get an RPC interface and are free to script it from anything you want (shell to Rust is about the range I’ve encountered). It does mean that you don’t get the batteries you get with Helix (e.g. LSP support) and need to bring your own (e.g. kakoune-lsp[2]). [1] https://kakoune.org/ [2] https://github.com/kakoune-lsp/kakoune-lsp | | |
| ▲ | celrod 19 hours ago | parent [-] | | Is including batteries the main reason helix seems to have started taking off, while kakoune hasn't? I use kakoune, because I like the client/server architecture for managing multiple windows, which helix can't do. The less configuring I do the better, but I've hardly done any in the past year. It's nice to have the option. I do use kakoune-lsp and kak-tree-sitter. |
| |
| ▲ | lemonberry 19 hours ago | parent | prev [-] | | I don't know if this is still the case but they were leaning towards Steel. Relevant Github comment: https://github.com/helix-editor/helix/issues/10389 Steel: https://github.com/mattwparas/steel |
|