icomplete-fido-backward-updir litters kill-ring

[Andrew Schwartzmeyer <andrew@schwartzmeyer.com>]

[-- Attachment #1: Type: text/plain, Size: 1753 bytes --]

Hello,

Please tell me if this should be redirected to the bug report mailing list. It’s less a bug and more an undesired behavior. While using fido-mode, I noticed my kill-ring just getting littered with…stuff. Turns out that icomplete-fido-backward-updir uses zap-up-to-char, which kills instead of deletes:

(defun icomplete-fido-backward-updir ()
  "Delete char before or go up directory, like `ido-mode'."
  (interactive)
  (if (and (eq (char-before) ?/)
           (eq (icomplete--category) 'file))
      (zap-up-to-char -1 ?/)
    (call-interactively 'backward-delete-char)))

(defun zap-up-to-char (arg char)
  "Kill up to, but not including ARGth occurrence of CHAR.
Case is ignored if `case-fold-search' is non-nil in the current buffer.
Goes backward if ARG is negative; error if CHAR not found.
Ignores CHAR at point."
  (interactive "p\ncZap up to char: ")
  (let ((direction (if (>= arg 0) 1 -1)))
    (kill-region (point)
		 (progn
		   (forward-char direction)
		   (unwind-protect
		       (search-forward (char-to-string char) nil nil arg)
		     (backward-char direction))
		   (point)))))

Since the function zap-up-to-char does a kill, if you’ve typed out a path /foo/bar/baz/, then decide to look elsewhere and hit DEL DEL DEL, they all get killed (not just deleted).

We could an optional arg to zap-up-to-char so that it can call delete-region instead of kill-region, or duplicate the code in it, or something else entirely.

João, what do you think? Perhaps this was intended behavior, but it doesn’t seem like it.

Thanks,

Andy

P.S. With Emacs 28 I’m super happy with how much 3rdparty stuff I’m getting to replace with GNU code, either built-in or in ELPA. Like fido-mode :)

[-- Attachment #2: Type: text/html, Size: 3897 bytes --]