countvajhula / countvajhula/lithium

[Improvement] Keybinding documentation and introspection

Open
#4 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Emacs Lisp
Stars
14
Forks
2
PR merge metrics
No merged PRs in 30d

Description

This is not urgent but would improve the UX.

The way Lithium sets up keymaps breaks Emacs default introspection methods by wrapping the actual bound functions into lambdas to properly handle modal lifecycle hooks.

Some discussion on this was done in https://github.com/drym-org/symex.el/issues/167

Some things that came to mind recently were the following:

1. Using hooks (and/or potentially much more messy, advice) instead of actually wrapping the function. For example, what if the hook handling behavior were put in the post-command hook using `last-command` or `this-command`. I recognize this would preclude some of the listed hooks in the previous discussion and add some caveats to the mode lifecycle stuff. I've looked at `lithium--handle-key` and (this may be naive) I wonder how bad would it actually be if all the mode error handling stuff were gone. I also wonder why the pre and post exit hooks can't be run in the mode function i.e. in the `(funcall #',mode -1)` call. The ultimate question is "why should the Lithium keybinding system be handling exiting the mode when a bound command errors. If the bound command is external to Lithium, then it should not be Lithium's problem and should be fixed in the command source or wrapped in a properly named function by the user or some other package. If the bound command and thus error is internal to Lithium (and thus something that would indicate the whole Lithium mode is horribly broken beyond recovery) than shouldn't the error handling be internal to that function (or if this is a more pervasive thing wrapped around all Lithium functions via a `post-command-hook` or a custom `lithium-defun` wrapper?
2. I forget the name of the feature (and which definition interfaces support it), but keys can actually be bound to a cons of a description string and the command (e.g. `(cons "display-name" #'command)`). This would enable some introspection utilities like which-key-show-top-level to at least show some information. This could be done in the `lithium-define-key` function.
3. Perhaps, instead of trying to intercept and modify help from the `C-h k` facility it would be better to build a custom lithium-help command which gets bound in some standardized way (similar to the C-h prefix) in Lithium maps. This still unfortunately leaves the problem of introspection from other means such as `describe-variable`/`helpful-variable` on the key maps, or `describe-bindings`.
4. What if only the commands that needed to modify modal life-cycle were bound to lambdas? This seems like it would improve the general situation even if it isn't a perfect solution from a technical sense. I.e. only the commands where `should-exit` is set are rebound with lambdas? I think that if this were done implementing 3 or something similar would still be worth it.

Hopefully this was helpful and we can find some way to improve the situation.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reading the lithium--handle-key and lithium-define-key entry points, then review the related discussion in symex issue 167. The issue needs a selected approach for preserving keybinding introspection while handling modal lifecycle hooks; done would require an agreed implementation and checks covering the affected help or keymap behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
emacs-lisp
Domain
developer-experience
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.