C-w in command mode and minibuffer inconsistent with Vim/evil

[totallyuniquelily]

I confirm that...

• I have searched the issue tracker, documentation, FAQ, Discourse, and Google, in case this issue has already been reported/resolved.
• I have read "How to Debug Issues", and will use it to provide as much information about this issue as possible.
• The issue can be reproduced on the latest available commit of Doom.
• The issue can be reproduced on a stable release of Emacs, such as 27, 28, or 29. (Unstable versions end in .50, .60, or .9x)

Expected behavior

Deleting words with C-w in the minibuffer and ex-commands¹ should function the same as C-w in insert mode, i.e. delete Vim/Evil words (sequence of word characters or non-word characters).
Probably call evil-delete-backward-word like in insert mode.

Current behavior

When typing in a command with : ¹ or in a minibuffer, C-w will call either backward-kill-word or doom/delete-backward-word. Both of these use the Emacs definition of words and not the Evil one as evil-delete-backward-word does

Steps to reproduce

1. Open Emacs (w/ Evil enabled as per default)
2. (optional) Open scratch buffer, insert some text, and C-w it
3. Open the minibuffer (e.g., by using M-x)
4. Type "test -- -test"
5. Press C-w twice
6. Observe the entire line being deleted, instead of just "-test"

System Information

https://pastebin.com/3uMUDVHx

Footnotes

1. edit: I believe the ex-commands case is an upstream issue (#1921). I've edited the report (and reproduction steps) reflect that ↩ ↩²

[hlissner]

This is not considered a bug, but I can understand how it can be frustrating. Refer to this section of evil's FAQ for details on how to understand and tweak word boundaries as Emacs sees them.

As word constituents are highly major-mode specific, and can influence parsers and syntax highlighting (and by extension, any commands that rely on them), it's isn't trivial to make them consistent in Emacs without stepping on some toes. Making them delete by vim's definition of word boundaries may work in one place, but not another, and having one set of rules in the minibuffer and another in non-minibuffer buffers is a recipe for a different kind of confusion.

As such, I prefer to leave it to Emacs' major modes (and users) to decide for themselves what trade-offs they're willing to live with.

Thanks for bringing it to my attention, in any case.

[hlissner]

Oh, forgot to mention. If you want to evil-ify just the minibuffer, another alternative is to enable evil-want-minibuffer:

;;; add to $DOOMDIR/config.el
(setq! evil-want-minibuffer t)

This will put the minibuffer in insert mode and, by extension, make it use evil's commands, rather than our generic ones. This also makes the minibuffer modal, so you switch to normal or visual there, which can be jarring for some. Again, you decide what trade-offs you're willing to live with.

[totallyuniquelily]

The FAQ entry is unrelated I'm afraid. I'm not making a word-constituents complaint at all, merely noting that the C-w minibuffer binding (provided by Doom) does not match the insert-state C-w binding. It could easily be fixed/worked-around with the following:

(map!
   (:map minibuffer-mode-map
      "C-w" #'evil-delete-backward-word)

The above fixes the part of the bug that is introduced by Doom, although more keymaps would need to be added to fix it for ex command-line, search, and the eval register (but those will probably be fixed upstream).

(note that the bug has arguably nothing to do with Vim. It's an inconsistency between keys within Evil/Doom)

While I'm responding, I would, however, note that fixing this may need to wait for the upstream bug to be fixed anyway, as otherwise we'd have to do one of:

• partial fix (causing inconsistency between ex and other minibuffers)
• full fix (causing duplicate bindings once upstream Evil is fixed)

In any case thank you for responding, and apologise if commenting on a closed issue (or if any of my wording) was rude.

edit: also the bug (in Doom) is literally just this line. I'd PR a fix, but it'd cause the aforementioned inconsistency until upstreaaam.