Even though keymaps are supposed to be undefined (I don't use dired-hacks, so dired-filter-mark-map is indeed never defined), my evil-collection-setup-hook that does keymap translations on the fly still tries do access the map, leading to this (lengthy) backtrace below:
Long backtrace, ignore the long lists of strings; those are the remappings
I know the stacktrace has some Doom Emacs in the middle, but it's a regression here, and the doom code called here hasn't changed in a while so I think it's still relevant.
I still don't know what evil-delay is supposed to do different than evil-with-delay, nor whether the (evil-collection--translate... calls in the new version are supposed to stay unquoted, but there's something that should not be evaluated that started to become evaluated.
Linked to #750, and to https://github.com/doomemacs/doomemacs/issues/7408
There's something weird going on with
evil-collection-setup-hooks
that seemed to appear since the change fromevil-delay
toevil-with-delay
in https://github.com/emacs-evil/evil-collection/commit/de0b62b604e87ce43e2adc9e09bcd5174e8b877a and/or the usage of Emacs 29.1.Even though keymaps are supposed to be undefined (I don't use
dired-hacks
, sodired-filter-mark-map
is indeed never defined), myevil-collection-setup-hook
that does keymap translations on the fly still tries do access the map, leading to this (lengthy) backtrace below:Long backtrace, ignore the long lists of strings; those are the remappings
I know the stacktrace has some Doom Emacs in the middle, but it's a regression here, and the doom code called here hasn't changed in a while so I think it's still relevant.
I still don't know what
evil-delay
is supposed to do different thanevil-with-delay
, nor whether the(evil-collection--translate...
calls in the new version are supposed to stay unquoted, but there's something that should not be evaluated that started to become evaluated.