Implement Helix keybindings + keybindings agnosticism #1877
Replies: 1 comment 2 replies
-
I don't think that Lem is intended to be an Emacs clone, it's more that is borrowing ideas from Emacs - but the developer has been very clear he does not like Emacs very much. I agree keybindings should be decoupled from the architecture, but I think they are in Lem. What I think you're talking about here is an interaction model. Emacs is a non modal editor, that with extensive hacks can be made (somewhat unsatisfactorily) modal. LEM has a vi mode that is a first class citizen (the author uses it), so it supports a modal interaction model for those that want it. Improving support for other forms of keyboard interaction (given that Helix is moderately different from VI) is supported in theory - it just requires the work to make it happen. I would start by customizing the vi mode to make it fit your needs and see where you end up. If there are things that need changing (inevitable given the selection first model) - either do pull requests for them, or raise issues. I don't think anyone is opposed to this - but I don't think anyone its a priority for anyone currently hacking on LEM. LEM has a small community of people working on it, and it currently has a lot of issues that need improvement, so resources are small. On the plus side, if you know Common Lisp - the code base is good, and decent PRs are usually accepted with minimal ceremony. And if you don't know Common Lisp, it's a great language... :) |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I think that Lem is super cool, as it can tap into the possibilities than Common Lisp brings to the table. But it doesn't deviate enough from Emacs to really stand out (I'm pretty sure that standing out wasn't the primary intention). Lem ist just a too shy approach – that way Lem is still just another Emacs clone that happens to be implemented in Common Lisp.
Keybindings are a particularly important interface, everyone has their opinion on what it's "best". Because of that, a particular keybinding set should not be a defining, deeply ingrained property of an editor, but "first class citizens" in so far that they are completely decoupled from the underlying architecture – meaning a philosophy of no keybinding set being "prior" to others.
Ideal: There would be a layer (or protocol) in between that makes it comparatively simple (for users) to define a keybinding set on top of that. There are seemingly 2 main factions: modal (VIM, Kakoune, Helix, Meow, God-mode) and non-modal (Emacs, VSCode + generic CUA). However, this "fundamental divide" is rather a false dichotomy – in the end it's just either having 1 single layer or n layers and switching between these dictates what input is allowed, quite like what we have in minimalist mechanical keyboards.
What I can see, there's nothing like that right now, every editor trying to impose it's own model of interaction and making a fuss of "modal" or "non-modal". Would be great to get away from that. But I can't really gauge what effort it takes to make it that way though.
That being said, the most consistant set of editing model I've encountered so far ar these of the Helix editor (from VI(M) -> Kakoune -> Helix), which gained some traction recently. I'm torn between Emacs and Helix right now, and I don't know how Helix will turn out with its WIP plugin system based on a Scheme interpreter and if there will be some "Emacs feeling" – meaning the deep integration and interaction of anything with everything else – eventually. But probably not.
Beta Was this translation helpful? Give feedback.
All reactions