Symex should inherit Evil Normal state keybindings

[Ramblurr]

I am very curious to try out symex 2.0 and take it for a spin! You've put a lot of work into it, and I'm excited to see that the previous deps (lispy etc) are removed!

However the first thing I noticed when entering 2.0 for the first time was the behavior of the space key in symex-editing-mode.

I use SPC as my leader key ala doom and spacemacs. I also use evil.

When I start symex-mode-interface with symex 2.0, the SPC key inserts a literal space. I would expect that to happen if I was in insert mode, but not symex-editing-mode

Is there a straightforward way to leave SPC as the leader key?

edit: 🤔 this also happens with the : key for evil-ex

I'm open to the idea that I am misunderstanding or misusing symex. However when editing lisp I like to more-or-less forget about evil normal mode and live in a loop between symex and insert modes. Having the power of the rest of my config with the : and SPC commands to launch builds, tests, etc, is important, and I'd rather not have to go back to normal mode for that.

[countvajhula]

Yes, this is straightforward and there are a number of ways to do it. Here's how I do it in my config:

(lithium-define-keys symex-editing-mode
    (...
     ("\\" my-local-leader)
     ("SPC" my-global-leader)))

(you'll need to bind these keys to the actual leader functions you use, which you could discover using C-h k SPC while in Normal state)

[source]

Some other options, FYI:

• Symex defines an Evil state in the symex-evil package. You could use Evil's evil-define-key to bind the leader in that evil state.
• Potentially, we could have this Evil state inherit Normal keybindings out of the box via evil-define-state's :enable normal, so that user customization isn't needed (IIRC I did try this and had some difficulty handling count arguments correctly? But it was a long time ago so things may have changed and it seems worth a fresh try).
• If that isn't viable, then we could augment the existing standard Evil bindings during Symex initialization.

For now, having these keybindings in user config is easy enough, but now that there is a dedicated symex-evil package specifically for Evil integration, we could potentially develop the most convenient integration with Normal over time (and input like yours is appreciated!).

Btw, you might be interested in Easy Entry into Symex Mode, especially recipe (3), which we are hoping to include out of the box in Symex soon.

[jmckernon]

Without commenting on what's straightforward or not to implement, I'll just say that I was surprised that unbound keys in symex mode insert into the buffer. This seems like almost never what you would want.

Having symex mode/state overlaid on normal state potentially makes sense, but obviously only helps evil users.

[Ramblurr]

Symex defines an Evil state in the symex-evil package. You could use Evil's evil-define-key to bind the leader in that evil state.

This was easiest for me. In my doom config it was as easy as (add-to-list 'doom-leader-key-states 'symex), this handles SPC. But doesn't handle any other keys (see below)

I'll just say that I was surprised that unbound keys in symex mode insert into the buffer. This seems like almost never what you would want.

Agreed.

I added :enable (normal) to symex-evil's evil-definte-state symex and now it behaves more like I would expect. I have not yet tried any actions with a yet though.

[countvajhula]

I'll just say that I was surprised that unbound keys in symex mode insert into the buffer. This seems like almost never what you would want.

Agreed.

Having symex mode/state overlaid on normal state potentially makes sense, but obviously only helps evil users.

Yes, good points, and sounds good to me. It works this way currently mainly because keys self-insert by default if there is no binding in any keymap, and having it not do that would require implementing the behavior to do nothing (i.e., in Lithium rather than Symex). I'm not familiar with a way to terminate key lookup when a key is not bound in a keymap, or provide a default binding for keys in a keymap that aren't explicitly bound. From a quick look at how Hydra does it, it looks like it adds a function to pre-command-hook and mutates this-command to a no-op if the key is unbound in the hydra map. I don't love this approach, but we could resort to it if it's the only option. I've created and linked an issue on the Lithium repo to get feedback on how to approach this --- thoughts welcome.

I added :enable (normal) to symex-evil's evil-definte-state symex and now it behaves more like I would expect. I have not yet tried any actions with a yet though.

This will likely break the handling of count arguments @Ramblurr , e.g., 3c or 2x, going by this comment. It may also affect repetition using . in combination with counts. Could you confirm if that's the case?

If these are indeed broken, you could try, in addition to :enable (normal), also explicitly binding the count arguments as:

(lithium-define-keys symex-editing-mode
  (...
   ("1" digit-argument)
   ("2" digit-argument)
   ("3" digit-argument)
   ("4" digit-argument)
   ("5" digit-argument)
   ("6" digit-argument)
   ("7" digit-argument)
   ("8" digit-argument)
   ("9" digit-argument)
   ...))

If that fixes it, then we could implement it this way in Symex itself, so you could avoid having this in your user config (which is brittle as it may drift from core symex).

[Ramblurr]

Here are the results of a few minutes of testing:

1. with no patches (symex as it stands now), the count arguments work, but symex mode is plagued by the issue discussed above
2. with the addition of :enable (normal) to (evil-define-state symex..., the issues above go away however count arguments are indeed broken.
3. by adding the digit-arguments to (lithium-define-keys symex-editing-mode... in symex-evil-initialize, the count arguments are still broken. Any other ideas for how to fix the count args?

Here is the patch I used in 3:

diff --git a/symex-evil/symex-evil.el b/symex-evil/symex-evil.el
index 1fe60e7..4403f76 100644
--- a/symex-evil/symex-evil.el
+++ b/symex-evil/symex-evil.el
@@ -105,6 +105,7 @@ right symex when we enter Symex mode."
 (evil-define-state symex
   "Symex state."
   :tag " <λ> "
+  :enable (normal)
   :message "-- SYMEX --")
 
 ;;;###autoload
@@ -116,30 +117,15 @@ right symex when we enter Symex mode."
   ;; disabled in symex state, which necessitates redefining the
   ;; relevant bindings in symex mode explicitly.
   (lithium-define-keys symex-editing-mode
-    (("u" evil-undo)
-     ("C-r" evil-redo)
-     ("\"" evil-use-register)
-     ("g;" evil-goto-last-change)
-     ("g," evil-goto-last-change-reverse)
-     ("gg" evil-goto-first-line)
-     ("G" evil-goto-line)
-     ("q" evil-record-macro)
-     ("@" evil-execute-macro)
-     ("m" evil-set-marker)
-     ("'" evil-goto-mark-line)
-     ("/" evil-search-forward)
-     ("?" evil-search-backward)
-     ("#" evil-search-word-backward)
-     ("*" evil-search-word-forward)
-     ("n" evil-search-next)
-     ("N" evil-search-previous)
-     ("C-d" evil-scroll-down)
-     ("C-u" evil-scroll-up)
-     ("C-]" evil-jump-to-tag)
-     ("C-i" evil-jump-forward)
-     ("C-o" evil-jump-backward)
-     ("C-p" evil-paste-pop)
-     ("C-n" evil-paste-pop-next)))
+    (("1" digit-argument)
+     ("2" digit-argument)
+     ("3" digit-argument)
+     ("4" digit-argument)
+     ("5" digit-argument)
+     ("6" digit-argument)
+     ("7" digit-argument)
+     ("8" digit-argument)
+     ("9" digit-argument)))
   ;; TODO: handle other undo systems?
   (when (and (eq 'undo-tree evil-undo-system)
              (fboundp #'undo-tree-undo))

[countvajhula]

That's very helpful data, @Ramblurr ! Re: ideas on how to get both to simultaneously work in a seamless way, the binding of the count arguments in the symex-editing-mode keymap that you tried really should work, since this map is at overriding-terminal-local priority (same as used by Hydra and Transient), which should typically override the Evil map. But I get the impression Evil does some fancy things specifically for count arguments to override everything else, even overriding terminal keymaps! If that's indeed what's happening here, then it might be necessary to understand precisely how Evil does that, and then perhaps use that same mechanism in symex-evil-initialize to override Evil. Since this function is called after Evil's initialization, it should give us priority.

My current recommendation: Until we have such a seamless way, manually re-binding Normal state commands in symex-editing-mode (without :enable normal) is the approach I'd recommend, as it works in every case but entails a one-time annoyance of adding the keybinding.

(Note: as @jmckernon pointed out, we're discussing two separate but related issues here, so I've gone ahead and renamed this one to be more specific to Evil, while the other, general issue about unbound keys being no-ops is tracked in countvajhula/lithium#3)

[yuki-tsubaki]

@Ramblurr I don't have much input on the "Integrate all the Evil stuff" (personally despite using Evil mode in most other places, I don't actually miss any Evil specific functionality in Symex mode).

I do however know what I do for getting my leader keys to work in Symex state: I just bind my leader keymap in symex state as well.

In your case:

  (evil-define-key 'symex 'global (kbd "SPC") my-map)

Where my-map is the keymap I want nested under my prefix (remember to define the keymap as a prefix keymap

(defvar-keymap my-map
  :prefix 'my-map
  ...)

For additional context, I also use this to bind the prefix in Emacs state as well (which I use in insert mode and some modes that I don't use evil in such as calc-mode). It has worked well for me.

As a final tip in case you weren't already aware, you can bind something in multiple states at once (I didn't do in the case above for the sake of modularity).

E.g. this makes the leader available in all the sane states I can imagine:

  (evil-define-key '(symex normal visual) 'global (kbd "SPC") my-map)