unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* icomplete-fido-backward-updir litters kill-ring
@ 2020-06-13  4:20 Andrew Schwartzmeyer
  2020-06-13 17:51 ` João Távora
  0 siblings, 1 reply; 2+ messages in thread
From: Andrew Schwartzmeyer @ 2020-06-13  4:20 UTC (permalink / raw)
  To: emacs-devel; +Cc: João Távora

[-- 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 --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: icomplete-fido-backward-updir litters kill-ring
  2020-06-13  4:20 icomplete-fido-backward-updir litters kill-ring Andrew Schwartzmeyer
@ 2020-06-13 17:51 ` João Távora
  0 siblings, 0 replies; 2+ messages in thread
From: João Távora @ 2020-06-13 17:51 UTC (permalink / raw)
  To: Andrew Schwartzmeyer; +Cc: emacs-devel

Andrew Schwartzmeyer <andrew@schwartzmeyer.com> writes:

> 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.

It's a bug, and yes, next time you should redirect this to the bug
report mailing list.  Just make sure you CC me in some reply to the
message that debbugs replies with (the one that includes the bug number
that it assigns automatically).  Don't CC: me in the original mail to
bug-gnu-emacs@gnu.org.

> João, what do you think? Perhaps this was intended behavior, but it doesn’t seem like it.
>
No, it's not intended.  It's a bug, and a pretty annoying one.  I've
fixed it in Emacs 27 (which should eventually appear in master).  Have a
try, please.

> 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 :)

That's good to hear.  I also like that feeling (but not all do, I
suspect).



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-06-13 17:51 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-13  4:20 icomplete-fido-backward-updir litters kill-ring Andrew Schwartzmeyer
2020-06-13 17:51 ` João Távora

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).