evil-snipe-override-mode causes delete/change/yank (d/c/y) commands forward (f) to space to not include space

[mplanchard]

What did you expect to happen?

Evil commands operating forward to space, e.g. d f SPC, should move up to and including the space, matching forward motion, e.g. f SPC, which moves to the space.

For example, with the text below, and the cursor in the indicated position:

here is some text
        ^

Pressing d f SPC should result in

here is text

The same should apply to changing (c) and yanking (killing in emacs parlance) (y).

What actually happened?

Commands operating forward to a space, e.g. d f SPC, act only up to the space, not including the space itself, matching the expected behavior for t rather than f.

For example, with the text below and the cursor in the indicated position:

here is some text
        ^

Pressing d f SPC yields (note the extra space):

here is  text

This seems to happen regardless of major mode (including both text and fundamental mode), and can be replicated in the doom sandbox plus modules minus private config, but not vanilla doom. My colleague has also seen this issue on a fresh install of doom emacs, running emacs from the terminal rather than in GUI mode.

Note that this does not affect forward motion, e.g. f SPC. That behaves as expected, moving the cursor to the next space character.

Describe your attempts to resolve the issue

To verify the source of the behavior, I ran vanilla doom via the sandbox (C-c C-d), opened a text file, and enabled evil-mode, and evil-snipe-mode. I verified the behavior of commands like d f SPC work as expected. I then enabled evil-snipe-override-mode and observed that d f SPC and friends do not delete up to and including the space.

I also verified on my regular emacs session that disabling evil-snipe-override-mode, which is enabled in doom by default, restores the expected behavior.

I initially opened an issue in doom for this, but then after some more searching in the doom configs, I found that it was enabling evil-snipe-override-mode, gave that a shot, and discovered it to be the cause. That issue is doomemacs/doomemacs#6041.

Steps to reproduce

1. Open doom emacs
2. Open the sandbox (SPC h E)
3. Open vanilla doom (C-c C-d)
4. M-x find-file and open a text file
5. M-x evil-mode
6. M-x evil-snipe-mode
7. Observe that d f SPC behaves as expected
8. M-x evil-snipe-override-mode
9. Observe that d f SPC no longer behaves as expected

Package commit

a79177d

System Information

Executing 'doom info' with Emacs 29.0.50 at 2022-01-25 20:34:43
generated Jan 25, 2022 20:34:43
system NixOS 21.11.20220121.e84444b (Porcupine) Linux 5.10.93 x86_64
emacs 29.0.50 master a82c3557f ~/.emacs.d/ -> ~/.emacs.d/
doom 21.12.0-alpha HEAD -> master, origin/master c7753adb 2022-01-15 21:14:55 +0100 ~/.doom.d/ -> ~/s/gh/mplanchard/githome/all/.doom.d/
shell /run/current-system/sw/bin/bash
features CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS XIM GTK3 ZLIB
traits batch server-running envvar-file custom-file
modules :completion company vertico :ui doom doom-dashboard doom-quit (emoji +unicode) hl-todo hydra modeline nav-flash ophints (popup +defaults) unicode vc-gutter vi-tilde-fringe window-select workspaces zen :editor (evil +everywhere) file-templates fold (format +onsave) multiple-cursors snippets :emacs dired electric ibuffer undo vc :term eshell shell vterm :checkers syntax spell :tools debugger docker editorconfig (eval +overlay) lookup (lsp +peek) (magit +forge +magit-todos +github-review) make pdf terraform :os tty :lang emacs-lisp (go +lsp) json (javascript +lsp) latex markdown nix (org +journal +pandoc +present +roam2) (python +lsp) rst (rust +lsp) sh web yaml :email (mu4e +gmail) :config (default +bindings +smartparens)
packages (ace-window) (browse-at-remote) (cargo-mode :recipe (:host github :repo ayrat555/cargo-mode)) (code-review) (csv-mode) (dap-mode) (dhall-mode) (direnv) (edit-server) (elpher) (evil-terminal-cursor-changer) (evil-textobj-tree-sitter) (exec-path-from-shell) (emms) (gh-notify :recipe (:host github :repo anticomputer/gh-notify)) (git-link) (hackernews) (ijanet :recipe (:host github :repo serialdev/ijanet-mode)) (janet-mode) (jest) (kaolin-themes) (kubernetes) (kubernetes-evil) (lsp-pyright) (magit-delta) (mermaid-mode) (mixed-pitch) (mu4e-views) (ob-typescript) (prettier-js) (pandoc-mode) (protobuf-mode) (pyvenv) (rmsbolt) (shfmt) (skewer-mode) (string-inflection) (tree-sitter) (tree-sitter-langs)
unpin lsp-mode lsp-treemacs lsp-ui
elpa vterm

[robbert-vdh]

Is there a workaround for this? This has been an issue for as long as I remember. d f SPC x to delete the leftover space has become muscle memory by now but it would be great to not have to do that.

EDIT: Setting evil-snipe-skip-leading-whitespace to nil gets rid of the issue, though disabling that option isn't always desirable.

[spacefrogg]

I took a look into this issue (for it buggerth me greatly).

Workaround: Set evil-snipe-skip-leading-whitespace to nil.

Its use is also the culprit in evil-snipe--seek. Whatever it is supposed to be doing. It is not doing it.