Help make vi-mode not feel like a second class citizen

[g-gundam]

Known Trouble Spots

• filer
• legit Bind for peek-legit-discard-file conflicts with vi-mode #1513
• dashboard
• color-theme-selector RET should invoke lem-core::color-theme-selector-select in vi-mode's normal mode too #1499

The common theme is that you have to be in vi-mode's insert mode to get access to the functionality of these modes. This feels very awkward from a vi-mode user's perspective. We should be able to make use of these modes from vi-mode's normal mode too.

Attempt at a Fix

The following is a naive attempt to make the color-theme-selector work while using vi-mode in normal mode. I know it's going to fail, but humor me.

(define-key lem-vi-mode:*normal-keymap* "Return" 'lem-core::color-theme-selector-select)

While this may make things work in color-theme-selector, it makes no sense in filer. For filer, I'd want something like:

(define-key lem-vi-mode:*normal-keymap* "Return" 'lem/filer::filer-select)

---

How do I configure things so that the appropriate function gets run when Return is hit depending on the current mode?

Does something like evil-collection need to exist for lem or is there a better way forward?

[g-gundam]

Part 1

A Proof of Concept using defgeneric

The keymaps for filer, dashboard, and color-theme-selector all have a special binding for Return. To make Return behave as vi-mode users expect in normal mode, we're going to take over the Return binding with our own function route-return. Its job is to figure out what the current major-mode is and use that information to dispatch to an appropriate handle-return method.

(in-package :lem-user)

(defgeneric handle-return (mode)
  (:documentation "Mode-specific actions for hitting Return."))

(defmethod handle-return ((mode (eql 'lem-core::color-theme-selector-mode)))
  "Return handler for color-theme-selector-mode"
  (lem-core::message "color-theme-selector-mode")
  (lem-core::color-theme-selector-select))

(defmethod handle-return ((mode (eql 'lem/filer::filer-mode)))
  "Return handler for filer-mode"
  (lem-core::message "filer-mode")
  (lem/filer::filer-select))

(defmethod handle-return ((mode (eql 'lem-dashboard::dashboard-mode)))
  "Return handler for dashboard-mode"
  (lem-core::message "dashboard-mode")
  (lem-dashboard::dashboard-open-selected-item))

(defmethod handle-return ((mode symbol))
  "Return handler that does the default action."
  (lem-core::message "default")
  (lem-vi-mode/commands::vi-return))

;; Every key that is taken over from *normal-keymap* would need one of these.
(lem:define-command route-return () ()
  ;; find the current major mode
  (let ((mode (lem-core:current-major-mode-at-point (current-point))))
    (lem-core::message (prin1-to-string mode))
    ;; dispatch to a method that can handle the given mode
    (handle-return mode)))

;; For now, just one key in *normal-keymap* is taken over,
;; but it could be many more in the future.
(define-key lem-vi-mode:*normal-keymap* "Return" 'lem-user::route-return)

If you add this code to your Lem config, filer, dashboard, and color-theme-selector will behave "correctly" in vi-mode's normal mode.

Hitting Return will perform the expected action without having to be in vi-mode's insert mode.

Thoughts on defgeneric

• I wanted to try defgeneric out, because multiple dispatch is my favorite feature from Julia, and I just recently learned that it originally came from Common Lisp.
• With that said, it might not be the right tool for this particular job going forward.
  • I'm concerned that the key name (the "return" in handle-return) is coupled too tightly with the various actions.
  • I might be overthinking this, but what if someone wants to put an action on a different key.
  • I also don't like that I had to use eql.
• I think the idea of introducing indirection to *normal-keymap* is sound, but a mechanism other than defgeneric should be explored.
  • However, one thing I do like about the defgeneric approach is that when a new mode is created, and they want to bind Return to do something, anyone could implement a handle-return method for that mode, and that's all it would take to make it work in vi-mode.
• I'm still playing with this idea and feeling things out.

[g-gundam]

Part 2

Work in Progress

Here's my current work in progress.
https://gist.github.com/g-gundam/0c06e910cc4a29f9b9444537f526f2e2
Although I called it "levi.lisp", in reality the contents are appended to the end of my init.lisp.

What works with no problems:

• color-theme-selector-mode
• filer-mode

These two modes only bind Return and that's one of the keys that I know how to take over from lem-vi-mode:*normal-keymap* safely.

Where I have problems is with the new dashboard-mode which binds more keys than just Return. The bindings that worked without any problems are:

• Return
• f
• l

The bindings that were broken to varying degrees are:

• g
• r
• s

"g" is a problem because in *normal-keymap*, there isn't a single character but a collection of many sequences like "g j" or "g u", and I'm not sure how to correctly intercept that. Just putting one new binding on "g" like the current code does isn't correct.

"r" and "s" are problematic, because the vi commands that they are normally bound to want parameters, and I have no idea what to pass to them. vi-replace-char wants 4 parameters and vi-substitute wants 3 parameters. I don't know how to get that info from Lem so that I can pass them along.

I commented "r" and "s" out, because they make vi-mode unusable when you're outside of dashboard-mode. Those who want to try anyway can uncomment the lines where those keys get bound and then M-x open-dashboard to see it work there, but once you're out of the dashboard, "r" and "s" will throw an exception.

Help me

I need someone who knows Lem internals better to advise me at this point. I also barely know any Common Lisp, and I'm learning as I go. If I'm doing something very wrong, let me know.

[CarsonEllsworth33]

I unfortunately know lems internals probably less than you and know Common lisp even less so, but I will be looking into both so I can assist in this endeavor.

[g-gundam]

Some pointers

Thanks for taking a look. Since I last wrote on this topic, I found that vi-replace-char which is bound to r and vi-substitute which is bound to s were initially defined using define-operator which is a macro that wraps define-command which is another macro. I just haven't taken the time to unravel what these macros do.

If these two macros were understood better, I think bindings like r and s could be intercepted safely and correctly.

I'm less sure about how to deal with things like g where I need to take over a leader key with a tree of subcommands under it.