emacs-evil-colemak-basic package's evil-search-next key mapping failes with Spacemacs.

[golanv]

Description

The wbolster/emacs-evil-colemak-basics (https://github.com/wbolster/emacs-evil-colemak-basics) seems to conflict with Spacemacs, notably with the search functionality. When this package is enabled, and upon searching for a keyword in the current buffer using "/", the correct keyword is highlighted, but the "next" key ("k" in the case of Colemak) searches for the previously searched keyword in reverse order instead of the present search term. Other keyword search term invocation methods, like "*", seem to work as expected.

Reproduction guide 🪲

• Start Emacs
• Add "evil-colemak-basics" to dotspacemacs-additional-packages in .spacemacs
• Add (use-package evil-colemak-basics :config (global-evil-colemak-basics-mode)) to dotspacemacs/userconfig defun in .spacemacs
• Restart Emacs

Observed behaviour: 👀 💔
As above

Expected behaviour: ❤️ 😄
The "k" key in the Colemak keyboard layout (QWERTY "n") should cycle in order through search keyword instances.

System Info 💻

• OS: gnu/linux
• Emacs: 27.2
• Spacemacs: 0.300.0
• Spacemacs branch: develop (rev. d63e172)
• Graphic display: t
• Distribution: spacemacs
• Editing style: vim
• Completion: helm
• Layers:

(javascript vimscript html python yaml auto-completion emacs-lisp git helm
            (haskell :variables haskell-completion-backend 'intero haskell-process-type 'stack-ghci)
            (clojure :variables clojure-enable-clj-refactor t)
            (sql :variables sql-capitalize-keywords t)
            multiple-cursors
            (shell :variables shell-default-position 'right)
            spell-checking syntax-checking version-control treemacs
            (latex :variables latex-backend 'company-auctex)
            pdf)

• System configuration features: XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS LIBSYSTEMD JSON PDUMPER GMP

[lebensterben]

Would it help if you

 (define-key evil-motion-state-map
      "k" 'evil-ex-search-next)

[golanv]

Would it help if you

 (define-key evil-motion-state-map
      "k" 'evil-ex-search-next)

Unfortunately, that seems to have no effect. I did add this to my dotspacemacs/user-config defun...please let me know if there is a better way of adding that mapping.

[lebensterben]

Aside from adding it to your .spacemacs, you can evaluate lisp forms by:

• In evil normal state, press : and the focus goes to the minibuffer.
• Continue to type the form "(define-key evil-motion-state-map "k" 'evil-ex-search-next)" and press return key.

---

Without the emacs-evil-colemak-basic package, you would find evil-ex-search-next is bound to k in evil-motion-state-map. (Note: after you press "/" in normal state, you're still in normal state. But evil works in the way that key bindings in motion-state would be searched after normal state. So normally, pressing n would result in evil-ex-search-next being executed.)

That's why I suggested to bind k to the said command in evil-motion-state-map.

---

I've no idea why it doesn't work.

With emacs-evil-colemak-basic loaded, and the above key binding registered:

What do you see if you M-x describe-key and then type n?

[golanv]

With emacs-evil-colemak-basic loaded, and the above key binding registered:

What do you see if you M-x describe-key and then type n?

"k" (Colemak):
k runs the command evil-search-next....

"n" (Colemak):
n runes the command evil-next-line...

So both of those look right. I did notice this quick error when reloading the .spacemacs configuration with evil-colemak-basics enabled that I didn't catch before:

Auto-evilfication could not remap these functions in 'tar-mode-map':

   - 'tar-chgrp-entry' originally mapped to 'G' 

[golanv]

Actually, after revisiting that, "k" does not look correct (it should be "evil-ex-search-next" after defining that key). It seems that with the emacs-evil-colemak-basics package installed and loaded, remapping that key (presumably all key mapping defined in that package) isn't possible.

Also, I would expect evil-search-next to have a similar behavior to evil-ex-search-next, but it does not seem to be the case (even without the emacs-evil-colemak-basic package enabled).

[lebensterben]

Try

(with-eval-after-load 'emacs-evil-colemak-basics
  (define-key evil-motion-state-map "k" 'evil-ex-search-next))

[lebensterben]

Also, it's their design choice to have
https://github.com/wbolster/emacs-evil-colemak-basics/blob/ddea4486de929c399745713a6e616df50b22dedd/evil-colemak-basics.el#L76
and
https://github.com/wbolster/emacs-evil-colemak-basics/blob/ddea4486de929c399745713a6e616df50b22dedd/evil-colemak-basics.el#L90

which is described in the second line of the table
https://github.com/wbolster/emacs-evil-colemak-basics#key-bindings

So it's not a bug of either Spacemacs nor evil-colemak-basics.
Therefore I'm converting this to a discussion.

[golanv]

Switching to isearch from evil search (adding "(evil-select-search-module 'evil-search-module 'isearch)" to the user-config section) results in a "k" key that works as expected. I guess I fail to understand the difference between evil-search-next and evil-ex-search-next why evil-search-next does not work properly with evil-search but evil-ex-search-next does.