Use Lithium instead of Hydra and Evil #20
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Hydra was useful to prototype Rigpa modes, but we need more lifecycle hooks in order to ensure clean mode entry and exit. There were a number of hacks in Chimera (the modal interface abstraction layer that was introduced specifically to abstract such hacks and present a simple modal API) to achieve an approximation of the expected behavior with mode transitions, but there were still some corner cases that could not be addressed. With Lithium, we use Emacs's built-in minor modes to implement the more rigid Vim-style (and yet, "point-free," Symex-style) modes we're looking for. This allows us to benefit from all of the existing infrastructure available for minor modes, and keeps the overlying additions "lightweight." By having an in-house, dedicated, modal interface framework, we also gain the flexibility to add the lifecycle hooks we need and tailor the implementation, without having to work around design choices that may have been made for requirements different from our own.
Mention including Lithium config as well since that package isn't on MELPA (or another package archive) either, and (as I understand it) cannot be declared as a dependency using `Package-Requires`.
countvajhula
changed the title
As a convention, we'll avoid specifying anything beyond keybindings in the mode definition, leaving everything else to happen via state lifecycle hooks.
This runs exit hooks for the previous mode and entry hooks for the new mode. We also don't run any hooks for Lithium modes which do all their hooks internally and via their exposed API. We currently use `manage-hooks` as a proxy for "is this a Lithium mode?" Just a temporary bridge to something more explicit.
This streamlines these actions so they're taken at the appropriate points in the mode transition lifecycle. Currently, some of these are no longer functioning correctly (e.g. keybindings no longer active in Symex state, #9), but we'll hopefully restore their functioning in a proper way as we go.
Rather than post-exit hook, as the latter is only called in the high level switch mode function and not the low level mode transitions used in enter-appropriate-mode.
Retain transparency menu in Hydra
We now use Lithium for global modes as it provides the lifecycle hooks we need to be able to cleanly treat it as a modal interface provider. We still use Hydra for features where a menu-driven interface is desired and not formally a modal one.
Also disable Evil Normal state in these modes as that would otherwise take precedence over the Lithium mode bindings.
For global modes, we need to do this to ensure that the mode reflects correctly in all buffers via the Evil state indicator, and all that these evil states don't take keybinding precedence over the active global Lithium mode.
This avoids encountering a `nil' evil state in some post-exit actions that were being performed "for all buffers" (as I recall).
countvajhula
changed the title
countvajhula
changed the title
1 task
Avoid defining these separately for each mode within Rigpa.
Don't rely on name-matching interning magic.
Checks if there is a lithium mode active, and otherwise uses evil state.
Now that Lithium supports mode "stacks," in some cases (i.e. native → foreign transition), we want the native mode to be preserved and the new one just pushed onto the mode stack. So in such cases, we do not exit the source mode before entering the target.
Don't attempt to enter any other mode, as with the mode stack, there should already be an active mode once the foreign mode has been exited (popped).
We no longer rely on the evil state as the source of truth on what the current mode is (except for evil-backed states, which currently are just the built-in evil states). But we do still rely on evil for UI feedback, to indicate visually which mode we are in, even for modes that are not evil-backed. We do this just because there is existing infrastructure for this for Evil, in the form of mode line enhancements and perhaps other things. Eventually we will likely want to move away from this, but for now, the only thing we still need to do upon exiting forreign modes is to enter the appropriate evil state for UI feedback purposes, which we do now instead of attempting to enter any particular local mode (which we don't need to do since there would still be a local mode on the stack upon foreign mode exit).
We no longer want to rely on evil as the source of truth for the "current mode."
Support symex implemented as a lithium mode
This still ends up setting the evil state in the original buffer rather than the timemachine buffer, though the evil state is set post-entry. Not sure why. Note the evil state is purely for UI feedback purposes and has no functional effect.
This is a general step towards maintaining a distinct notion of a current mode within Rigpa, which may use the current mode reported by Evil or Lithium as part of its operation. But it also is in response to a bug where [u]ndo'ing while in Symex mode causes the level to be reconciled to the level of Normal in the current tower (e.g. 2), even though we remain in Symex state. This seems to happen because as of emacs-evil/evil#1888, undoing explicitly goes into Normal state first, and then returns to whatever the original state was. In Rigpa, Normal is backed by Evil but Symex is backed by Lithium, even though it sets the Evil state for UI feedback purposes. As a result, we only watch the Evil state transition to reconcile the level when entering Normal state, but not Symex state, since we do not expect the Evil state transition to be the way in which Symex state is entered (it's rather just an effect of Symex mode entry via Lithium). As a result, during the undo operation, we see the transition to Normal and reconcile the level to 2, but do not see the transition back to (evil) Symex state, and thus do not reconcile the level back again to 1. This fix alleviates the bug because even though `rigpa--reconcile-level` is still only called upon Normal state entry, it does not result in the level actually changing because Rigpa's determination of current mode now first checks whether a Lithium mode is active, before checking the evil state. So even though the latter has changed during the undo operation, the mode remains the same as before, as the former has not changed.
While in replace state, escaping was having no effect. As it is considered a foreign state, it attempts to only exit the mode, which for evil-backed modes is a no-op. Additionally, as it isn't a lithium mode, there isn't even a notion of a stack wherein exiting replace mode would reinstate any prior mode. Escaping to normal seems the most straightforward thing to do, but I'm not sure if there may be a more correct handling.
Formerly I think with hydra we were implicitly exiting. With lithium, global modes like Buffer remain active even when the original buffer is killed, so we need to explicitly exit at the appropriate time.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary of Changes
This reimplements all modes using a lightweight modal interface framework (Lithium) instead of Hydra (currently used for global modes like Window and Buffer) and Evil (currently used for local modes like Line and Word).
Hydra was useful to prototype Rigpa modes, but we need more lifecycle hooks in order to ensure clean mode entry and exit. There were a number of hacks in Chimera (the modal interface abstraction layer that was introduced specifically to abstract such hacks and present a simple modal API) to achieve an approximation of the expected behavior with mode transitions, but there were still some corner cases that could not be addressed.
Evil on its own is local to buffers and so cannot be used to implement global modes. It also is a somewhat heavyweight way to implement the fairly limited modal functionality we need.
With Lithium, we use Emacs's built-in minor modes to implement the more rigid Vim-style (and yet, "point-free," Symex-style) modes we're looking for. This allows us to benefit from all of the existing infrastructure available for minor modes, and keeps the overlying additions "lightweight." By having an in-house, dedicated, modal interface framework, we also gain the flexibility to add the lifecycle hooks we need and tailor the implementation, without having to work around design choices that may have been made for requirements different from our own.
Addresses #16 .
Public Domain Dedication
(Why: The freely released, copyright-free work in this repository represents an investment in a better way of doing things called attribution-based economics. Attribution-based economics is based on the simple idea that we gain more by giving more, not by holding on to things that, truly, we could only create because we, in our turn, received from others. As it turns out, an economic system based on attribution -- where those who give more are more empowered -- is significantly more efficient than capitalism while also being stable and fair (unlike capitalism, on both counts), giving it transformative power to elevate the human condition and address the problems that face us today along with a host of others that have been intractable since the beginning. You can help make this a reality by releasing your work in the same way -- freely into the public domain in the simple hope of providing value. Learn more about attribution-based economics at drym.org, tell your friends, do your part.)