Include local minor mode for mode-specific but not editing-specific symex keybindings

[yuki-tsubaki]

Before 2.0 I had set up keybindings for Evil mode that manage entering the Symex editing state.

Among other things, I bound <escape> in the insert state of symex-mode-map to symex-mode-interface thus effectively swapping normal state and Symex as my default editing state.

In 2.0 symex-mode is a global minor mode. While this is probably important for some things, it breaks this workflow as there isn't really much of a concept of Symex being enabled in a specific buffer, but rather being enabled in all buffers with the specific Symex functionality always available if one calls synmex-mode-interface.

I don't know if this is the best way to solve it, but my first thought after I noticed I can't use symex-mode anymore was to define a new minor mode (maybe symex-available-mode) with a keymap and then use that.

The idea would be to hook symex-available-mode into modes where having the Symex editing state available makes sense. This would seem to fix my usecase without interfering too much with the new architecture.

On the other hand, if symex-mode (and the like) don't need to be global minor modes, it would be more clean to just use them (which for my use, only requires defining the symex-mode-map variable before defining the minor mode).

[countvajhula]

Try symex-editing-mode?

symex-mode is, as you noticed, the global mode that sets up the ability to use Symex in any buffer. But the actual mode that is active in any particular buffer while you are "in" Symex mode is symex-editing-mode (and it is local).

[yuki-tsubaki]

Oh wow, that was a fast reply.

I tried symex-editing-mode first, but the main problem there is that it is only active when Symex is, well, editing. Like when nodes are being selected and all the keybindings are active.

I was looking for a clean way to bind symex-mode-interface in a buffer/mode local way. I want that bound in relevant buffers even when symex-editing-mode is not active because it is the key to activate symex-editing-mode.

Using the proposed mode name I talked about the flow I am talking about is this:

• I hook the symex-available-mode into relevant modes like Lisp modes
• Using the keymap of symex-available-mode which contains a binding for symex-mode-interface I can activate symex-editing-mode.
• I don't want to use a global binding for it because I want it convenient in relevant buffers to the extent of overriding keybindings that are much more useful in other modes (e.g. evil normal state)
• I can't bind it in symex-editing-mode because the whole point is activating and deactivating symex-editing-mode

Hopefully I was more clear this time.

[yuki-tsubaki]

Hmm, so I was working on the face issue and as I was working I forgot I was tinkering with this before and ended up reloading it with the changes and (so far) it actually seems to have worked (which was a bit surprising because I assumed there was some big reason to have it be global now).

All I did was just get a keymap for symex-mode and make the mode local.

(defvar-keymap symex-mode-map
  :doc "Keymap active whenever `symex-mode' is active, not just
`symex-editing-mode'. This can be useful for defining a `symex-mode'
specific keybinding for `symex-mode-interface'.")

...

;;;###autoload
(define-minor-mode symex-mode
  "An evil way to edit Lisp symbolic expressions as trees."
  :lighter " symex"
  :global t
  :group 'symex
  (if symex-mode
      (symex-modal-initialize)
    (symex-modal-disable)))

With that all you need to do is hook symex-mode into any modes that you want it enabled in.

For me that is just adding:

  :hook (lisp-data-mode scheme-mode)

Into my use-package for symex.

If you did want to try this route it would just be a little tweak in the install/configuration stuff adding the hook stuff, and changing the binding for symex-mode-interface to a symex-mode binding.

If you want it a bit more global (after all I haven't even tried the TS modes and so I basically only need two hooks to get it enabled everywhere I want) while keeping the configuration easy (i.e. so you don't need to list every language you want it enabled in), you could maybe define a blacklist modes list and a check in the symex-mode minor mode definition that only enables the mode if the current mode is not in the blacklist.

Either way, I definitely prefer this general approach because it lets me bind the symex-mode-interface command only in buffers where I probably want that to be easily accessible. The previous version had me accidentally entering symex-editing-mode in places like the minibuffer and dired.

On the off chance that someone wants to access it from literally anywhere, they could still define a global binding just as you do in the current version of the readme.

(global-set-key (kbd "s-;") #'symex-mode-interface)

Unless there is some gotcha that I've been missing so far that needs symex-mode to be global, I think this approach makes it way easier to configure for my use case (and potentially many others who want it easily accessible in only a few modes but don't want it everywhere) while keeping the current way (i.e. global symex-mode-interface binding so that you can always access symex-editing-mode) just as accessible.

In fact, not that I think about it, I might bind a global key (though something a bit more difficult to accidentally trigger and not in the place of my way to get to normal mode) as well so I can easily use Symex when there is a bit of Lisp code in a non-Lisp buffer.

Anyway, I'd love to hear your feedback on this.

[yuki-tsubaki]

Ok, I implemented what I was talking about previously.

You can see what I did at yuki-tsubaki/symex.el/local-symex-mode-and-keymap.

The summary of how my verion works is basically:
symex-mode is a local minor mode. You hook it into modes as you see fit. Running symex-mode-interface runs (symex-mode) if it wasn't already enabled so that anything that needs to be setup is setup. I also made a symex-disabled-modes variable (customizable) that facilitates enabling modes using base modes hooks (like prog-mode) and then disabling some children as exceptions.

This overall should give a nice balance of easy setup (even for people who want to have it in many modes) and configuration.

As mentioned before, the current flow (global binding) still works with this while it also enables the mode local symex-mode-interface binding flow that I wanted to use (the same one as in #24).

I didn't update the manual or readme in my branch because I wanted to get your feedback first.

If you like it I can do that and then open a pull request.

[countvajhula]

Hey, thanks for this. Some feedback:

• symex-mode is global because it does one-time setup of things like initializing repeat parsing (for the "dot" command), setting the user's preferred up/down orientation, ensuring that lithium's global mode is enabled, registering one-time hooks to cleanly enter and exit symex mode, etc. Some of these could potentially be done in a local mode, but I'm not sure if all of them can be.
• For the mode you're talking about, how about a distinct mode called symex-local-mode?
• symex-disabled-modes: I like this idea as it's backwards compatible and wouldn't require existing users to introduce fresh config.

Finally, I actually think this approach calls for a refactor of symex-lisp-mode (which is what the old symex-mode is renamed to in 2.0), because currently, symex-core-mode enables it in all known Lisp modes.

Do you have any suggestions on how to handle symex-lisp-mode in your approach?

For now, we could define symex-local-mode in the symex-core package, and extend it with a default keybinding for symex-mode-interface in the higher-level symex package. I think that would be sufficient for the moment, and we can tackle symex-lisp-mode down the line, unless you already have any brilliant ideas for it :)

I'm also open to making symex-mode itself a local mode, if you feel that would be better, but we would need to find alternative and good ways to do what it currently does.

If you like, you're welcome to start a PR for this. Please be aware though that I'm currently still prioritizing release activities like following up with MELPA/NonGNU ELPA, and I may be slow in following up.

[yuki-tsubaki]

Ok sounds like keeping symex-mode global is the way to go then.

symex-local-mode sounds like a fine name too, though I do think with all the different modes we have we might want to give it a name that is more descriptive of its purpose. Like not knowing the intent behind the mode, I would be confused as to why/when symex-local-mode should be used especially given that symex-mode is already enabled and is global. That is kind of why I thought of symex-available-mode. But I might think it is more intuitive then it actually is. The idea is to "turn on symex-available-mode when you want the symex-mode-interface to be available available in the current buffer. Though again this isn't that important and it is the functionality that matters most.

Finally, I actually think this approach calls for a refactor of symex-lisp-mode (which is what the old symex-mode is renamed to in 2.0), because currently, symex-core-mode enables it in all known Lisp modes.

Oh yeah that does sound a little unexpected. Like I thought symex-core stuff was all stuff that doesn't do anything to the editing facilities (like basically just a library for the DSL and stuff). Is there any reason why you don't want those modes in the Symex package, or am I just misunderstanding the organization. I thought the Symex package was the home for all things UI besides extra special features like integrations.

unless you already have any brilliant ideas for it :)

No brilliant ones, but I feel like having it automatically hooked in all known Lisp modes sounds reasonable. Users could still manually hook it into other modes if they want (but I assume as long as you are using the base major modes that all lisp-like major modes will inherit from there). I think we could just reuse the stuff from symex-disabled-modes for the Lisp mode too if we want to make it a bit more configurable without loosing the 'works with no config' feel.

I'm also open to making symex-mode itself a local mode, if you feel that would be better, but we would need to find alternative and good ways to do what it currently does.

Actually, I should have read the whole thing before responding. I think this might be the most clean feeling solution.

For the initialization, I think we have 3 options:

1. Wrap the global initalization to eval only once globally, and don't bother making a mode to enable and disable it. The only thing that gets done to turn it off is symex-repeat-teardown and honestly it sounds like something that most people don't need to ever invoke. If all symex-mode does is set things up to work when the time comes, unsetting up seems like something only a developer or maybe someone with very specific needs would ever care about. I don't think we need a mode let alone one bearing the namesake of the entire package dedicated to initialization and uninitialization if that is really something that only needs to be done once for most people. Modes are (in my opinion) for something that you need to be able to enable and disable. That doesn't seem to be the case here.
2. Just do the global initialization (like in version 1) in the package setup. Let interested parties know and use symex-modal-disable if they so choose, but don't dedicate any modes to initialization and tear-down.
3. If you think a mode is warranted for toggling, then move this into a symex-global-mode or something. This seems a bit confusing again because it goes against the common logic that symex-global-mode should do the exact same thing as symex-mode but in all buffers.

I think option 2 sounds the best to me. Setup and initialization seems like functionality that is distinct from a mode. This also then frees up symex-mode to be a local mode which aligns more with what I would expect it to do: enable Symex specific functionality in the buffer I'm in.

Finally, unless I am just misunderstanding the core mode and the workings of the DSL are dependant on keybindings in symex-lisp-mode to work as a library, I think enabling it would best be done in the initialize function (if we use mode hooks for it), or as a conditional in symex-mode that will initialize symex-lisp-mode if the mode is in symex-lisp-modes (which as a side-note, could be improved by checking mode inheritance like I do with the disabled handling).

  (let ((disabled-mode (seq-find #'derived-mode-p symex-disabled-modes)))
    (if disabled-mode ...

We could simplify the list then and it would be more robust to Lisp modes that are unknown. For example, despite your already very comprehensive list, I can already think of a lispy mode that is not in your list: [[https://github.com/kmonad/kbd-mode/tree/master][kmonad/kbd-mode: Emacs mode for syntax highlighting kmonad's .kbd files.]]. Since they (and probably basically every other niche lispy mode) derive from a Lisp mode, this would be automatically handled if we used hooks or the enable list thing checking for inheritance.

If you like, you're welcome to start a PR for this. Please be aware though that I'm currently still prioritizing release activities like following up with MELPA/NonGNU ELPA, and I may be slow in following up.

No worries, I'm busy with other stuff too rn too. I probably won't do the PR until I have a good idea of what the vision is going forward. It should be pretty easy to do, I just need to know where we're going with it.

[tommy-mor]

just popping in to say that I also am having problems with symex 2.0 and getting my recipe to work.#24

[countvajhula]

@tommy-mor Have you tried using that recipe with symex-lisp-mode? I think that should work, for the moment, as the original symex-mode was just renamed to symex-lisp-mode.

There's a lot of good stuff in @yuki-tsubaki 's observations above to think about regarding a proper long-term fix, but I haven't had a chance to, yet.

[countvajhula]

This section of the docs re: upgrading from v1 to v2 may also be helpful. Please lmk if you run into any other difficulties as it would be great to ensure that section is comprehensive in helping users upgrade!

[jmckernon]

I hope this won't be an inappropriate place to share a few lines of config I put together to get 'return to symex state if we entered insert state from there' working. (i.e. what @tommy-mor was attempting.)

When leaving insert state, we want to return to symex state, if that's where we came from. Binding <escape> in insert mode to a function with the appropriate logic appeared to work; however, somehow it also seemed a little less elegant. Using an evil hook (evil-insert-state-exit-hook/evil-normal-state-entry-hook) appears a sensible solution at first glance; however, setting evil state in one of these causes issues: in a state exit hook, it causes an infinite regress (leaving the state requires us to leave the state which requires us to...). In an entry hook, it seems to be leave evil in a confused state, half in the state you want and half in the state it was entering anyway (notably, evil-state ends up out of sync; possibly there are other issues).

Below is my best working solution: :after advice to evil-normal-state. This sounds a bit fragile but so far appears to work. Input welcome.

(defvar-local entered-insert-from-symex nil
  "Did buffer's most recent entry into insert state come from symex state?")

(add-hook 'evil-insert-state-entry-hook
          (lambda ()
            (setq entered-insert-from-symex (eq evil-previous-state 'symex))))

;; when returning from insert state, go back to symex state if it's whence we came
(advice-add 'evil-normal-state :after
  (lambda (&rest _)
    (when (and (eq evil-previous-state 'insert) entered-insert-from-symex) ; when we're coming from insert state, and got thither from symex state
      ;(setq entered-insert-from-symex nil) ; this seems to be redundant, but would make doubly sure it's just a one-shot
      (symex-mode-interface))))

Btw, congrats @countvajhula on getting v2.0 out.

[countvajhula]

That seems like a fine approach @jmckernon , and I love the comments! Thanks for sharing -- I've added it to the manual.

I've been planning to officially announce the v2 release once the MELPA submission resolves (one way or the other), as well as after developing any necessary tools to make it as convenient as possible for people to install Symex if indeed it will not be distributed on MELPA. Unfortunately, I'm out of action on Emacs work at the moment as my old companion Ferdinand is sick, and I need to take care of him.

[jmckernon]

Happy for it to go into the manual (or indeed into the codebase) if useful.

Best wishes to Ferdy!