countvajhula / rigpa Goto Github PK

Hello,

I'd like to report that the parsec package seems to be missing from the Packages-Requires dependencies in: https://github.com/countvajhula/rigpa/blob/master/rigpa.el.
I've tried to install the package with straight.el and ended up with the following error:

Debugger entered--Lisp error: (file-missing "Cannot open load file" "Aucun fichier ou dossier de ce type" "parsec")
  require(parsec)
  ...

P.S. Thanks for your presentation at EmacsConf 2020, I really enjoyed it !

I'm on an Ubuntu box and don't have Consolas installed. Because the Consolas font is attempting to be set on line 68 of rigpa.el, I wasn't able to build rigpa until I commented out that line:

https://github.com/countvajhula/rigpa/blob/master/rigpa.el#L68

@countvajhula Aha, I've found your "mode-mode" at last! Here I think is huge potential for this idea

I really like corkey's idea of signals, which decouple conceptual operations (e.g. "eval current form") from concrete and mode-specific implementations.

There is a lightweight (57 sloc) package around this idea here:
https://github.com/lilactown/kitten/blob/main/lisp/reflex.el

that let's you write code like this:

binding keys to signals:
https://github.com/lilactown/kitten/blob/main/user/keybinds.el#L91-L112

providing functionality to the signals for a given mode:
https://github.com/lilactown/kitten/blob/main/modules/kitten-clojure.el#L40-L57

See also drym-org/symex.el#65

Introduce spatial navigation of Rigpa through all referential planes -- that is, make navigation from ground to referential levels, as well as change of perspectives in referential levels, map to spatial keybindings involving hjkl, instead of relying only on Esc/Enter with modifier keys. This should retain some uniformity in changing perspectives on ground editing (e.g. Insert/Emacs mode vs Normal/Line) vs changing perspectives on a meta plane (e.g. Insert vs Line mode in editing a tower), and navigation in these different "directions" should have spatial keybindings even if they also have convenient alternatives overloading Esc.

Workaround: Enter view mode again and exit it by hitting Enter or Escape.

Description: View mode is a hydra-backed mode. Hydra supports many different ways of exiting, one of which is exiting via a "foreign key," that is, the hydra can be configured to exit when a key not explicitly handled by the hydra/mode is pressed. This behavior is desirable for modes like View mode, where we typically use it in a transitory way, and would like it to disappear when we start doing the thing we really want to do.

Rigpa, as a modal interface framework, is interested whenever a mode is entered and exited, no matter which modal interface provider is being used. We would like to take certain actions upon mode entry and exit, for which we need to formally tie into mode lifecycle hooks. Rigpa relies on the chimera abstraction layer to make the determination that a mode has exited. As there does not seem to be a post-exit hook in hydra, Chimera relies on the after-exit hook to detect this event, which treats a semaphore in the post hook being set as indicating that the mode has truly exited. This is a roundabout way to do it, but was necessary without a true post-exit hook being present. Unfortunately, exiting a hydra through a "foreign key" does not call the after-exit hook. So if View mode is exited without explicitly hitting Enter or Escape, the cursor does not reappear (it is hidden upon View mode entry).

That said, this bug is recent and this did not happen before. I think it was probably introduced in e51b14b.

Fix: Either (a) request a true post-exit hook from hydra itself, (b) or write a minimal modal interface provider that exposes lifecycle hooks, or (c) revert to the old way of handling hooks in Rigpa.

Currently, Rigpa comes with some editing structures pre-defined, such as modes, towers, and complexes. There is an implicit top-down ordering here, where editing complexes contain towers which contain modes. Instead, it would be better to start from the ground, and find some way to delegate the UX to structures "discovered" when escaping into larger scales and meta levels. For instance, an inner level should not know that it is contained in a particular type of larger-scale structure.

This might necessitate:

• discovering containing structures using a lambda rather than through a hardcoded access of a known containing structure
• basic mutable structures (e.g. a simple list) to be able to add containing structures dynamically, so that they can be discovered through the discovery mechanism. When there is no containing structure discovered, it may need to be dynamically and automatically created in some cases.
• A UX abstraction layer that allows the discovery process to discover new keybindings that are appropriate for the containing structure's topology. E.g. a tower may involve up/down, but a ring may involve left/right rotation, and an array may involve translation in four directions. Most likely, we can just enter an appropriate mode here, and it won't involve making anything new, aside from possibly needing to have a mechanism to tie a structure to a mode.
• There may also be built-in ways to represent different types of structures (e.g. buffers for a complex, a single buffer for a tower, TBD for a ring), which could be determined by the type of structure.

In-buffer modes like Normal, Symex, Line, Character, Word modes are currently implemented using Evil.

Global modes like Window, Buffer, View modes are currently implemented using Hydra.

Hydra doesn't provide lifecycle hooks for every stage of entry and exit from a Hydra, since it isn't exactly designed to be a modal interface (although it's a pretty good one!). This means that we cannot always detect when certain things have happened, and thus, "recalling" appropriate in-buffer modes when exiting a hydra isn't always possible, and we sometimes end up in the wrong state, or aren't able to perform other necessary exit actions (see #10 ).

There may be many ways to address this, but for now, to get a prototype working in the intended way, it would be good to write a lightweight modal interface, perhaps just a global minor mode that uses an emulation mode keymap, and see if, once it is abstracted as a Chimera modal interface provider, if we can restore the correct behavior in terms of hooks and entry/exit actions.

That would of course lose the nice menus that we get with Hydra. But once we have the lifecycle working, we would at least have a clearer idea of the hooks that are needed, and whether it would make sense to continue using Hydra or add a menu to the lightweight modal interface. It would be easy enough, with Chimera, to swap them whenever we like.

(Note: the workaround below has already been added to the Rigpa Emacs config in the README. It will be removed once we have a fix.)

As a result of a recent change in Symex, entering View mode or Window mode momentarily (to e.g. adjust the zoom level) and then returning to Symex mode loses the symex keybindings. The bindings are restored upon re-entering Symex state once again.

(Scroll to the bottom for a workaround)

Explanation
This happens because the fix in the symex package involved adding a hook to disable the editing minor mode in case rigpa isn't present, to ensure that the bindings are disabled upon exiting symex state. This behavior conflicts with Rigpa's handling of the same functionality. They ordinarily should not interfere since symex defers to Rigpa's handling if it knows rigpa is installed.

But at the moment, Rigpa (via init.el configuration) loads after symex (I don't recall exactly why at the moment), so at the time Symex loads on emacs init, rigpa isn't available and the hook to disable the minor mode within Symex gets initialized, causing it to interfere with Rigpa later on.

Workaround
The workaround for now is to evaluate this expression sometime after Emacs loads:

(remove-hook 'evil-symex-state-exit-hook #'symex-disable-editing-minor-mode)

Possible Fixes
A proper fix would be to:

1. understand why Rigpa disables minor modes on the entry hooks to other states rather than on the exit hook of the concerned state (I think there was a reason, but it would be nice if we could do it on the latter, since that's cleaner and it's what Symex does now)
2. avoid dependence of these packages on one another at load time. Or at least, have Symex load after Rigpa
3. Ideally make the behavior here compatible across the two packages whether the other package is installed or not
4. Worst case, explicitly disable third-party (i.e. Symex) hooks in Rigpa that may interfere with its functionality

Hey! I can feel your energy. We could collaborate on making a better code interface. I am working on a very wide/deep project to do just that. Do you know of shen? Seeing qi reminded me of it, and I'm using shen to bootstrap a better language as well. Please get in touch. https://kriom.me

PS: Are you aware of this jaw-dropping fact?
https://www.youtube.com/watch?v=a7pd-TH-grI

When running emacs in a terminal with the -nw flag, rigpa.el cannot load because it tries to pass the 'unspecified font from the 'default face to #'font-get. Below is the stack trace of the error:

Debugger entered--Lisp error: (wrong-type-argument font unspecified)
   font-get(unspecified :name)
   (cond ((find-font (font-spec :name "Consolas")) "Consolas") ((find-font (font-sp$
   (set-face-font 'rigpa-face (cond ((find-font (font-spec :name "Consolas")) "Cons$
   #<subr eval-buffer>()
   apply(#<subr eval-buffer> nil)
   eval-buffer()  ; Reading at buffer position 3119
   funcall-interactively(eval-buffer)
   command-execute(eval-buffer)

I submitted a pull request with a quick fix; I hope that's helpful: #7

This is such a fantastic idea! I loved your EmacsConf 2020 talk. This makes me want to modify my entire Emacs setup that I have been using for many years to use this instead.

I am curious about your future plans for this package.

This is probably an annoying question, but do you think your code could be made independent from evil mode? It would be great if a user could select whether or not they would like to depend on evil mode and use its key bindings or use more traditional Emacs keybindings or something totally custom.

Right now it seems like the key bindings are pretty deeply embedded into each mode. It seems like all bindings would have to be changed in each mode in order to switch from evil bindings to Emacs bindings. That could require a huge amount of configuration if the user does not want to use your default settings.

It might be nice to have some more generalized motion primitives with key bindings for those set in one place, something like "forward", "backward", "up", "down", etc. Then the same key could be used for "forward" in every mode and every mode would just change what "forward" means, saving you from having to put a specific key binding into each mode. There would still need to be unique key bindings for some modes, but it would be great to reuse as many as possible for every mode. I am not sure what all of the other generalized primitives would be, what else tends to be common in all of your modes?

Another awesome feature would be to have the option of seeing where all of the motion commands will move for each mode, like how you can see where you are about to jump in avy mode. Like if you had the "h" key assigned to "backward" and "l" assigned to "forward", in word mode the letter "h" would be on top of the previous word and "l" would be on top of the next word, showing you where you would jump if you pressed those keys. In line mode the "h" and "l" would be on the previous line and next line, in window mode they would be on each of the windows where you would jump, etc. Every time you switched modes, those indicators would jump to their new locations. That would give really useful super fast feedback on where you can move without having to look down at the mode line to see what mode you are in or have to remember exactly what each mode means.

Thank you so much for your great idea and amazing work!

Rigpa maps the Enter key to entering a lower level in the current editing tower, overriding the handling in the underlying major mode. In many major modes, there is a more natural interpretation of the Enter key provided by evil-mode or evil-collection for that mode -- e.g. typically non-editing buffers like popups, dired buffers, Magit buffers, etc, where we would like Enter to "visit" or "choose" something. To restore this preferred handling of the Enter key, Rigpa currently manually remaps the Enter key to the preferred command in known cases - in other words, overriding its own override of the keybinding for that major mode - so that the Enter key behaves the way we expect in such buffers.

This is not a real solution. Besides requiring manual work to add these double-overrides (and needing to know about such cases), it also doesn't always work. In Magit, for instance, the same keybindings in different parts of the buffer seem to be bound to different commands (e.g. in the stashes section vs the commits section). I'm not sure how that is accomplished, but it means that a simple manual double-override is not possible here, and Enter does not do what we expect in Magit (workaround: temporarily go to Emacs state (e.g. via C-z) and then hit Enter).

In principle, it would be great if we could simply defer to a lower-priority keymap. That is, in resolving a keybinding, Emacs has a prioritized list of keymaps, and it consults them in order until a binding for the input keys is found. It would be great if we could say something like "if major mode = Magit, then I abstain from specifying the binding - please continue consulting other keymaps". Otherwise, is there another standard way in Emacs to do something like this?