GNU bug report logs - #48657
Defvar delimiter for dired-copy-filename-as-kill

Previous Next

Package: emacs;

Reported by: Rodrigo Morales <moralesrodrigo1100 <at> gmail.com>

Date: Tue, 25 May 2021 19:21:02 UTC

Severity: normal

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48657 in the body.
You can then email your comments to 48657 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#48657; Package emacs. (Tue, 25 May 2021 19:21:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Rodrigo Morales <moralesrodrigo1100 <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Tue, 25 May 2021 19:21:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Rodrigo Morales <moralesrodrigo1100 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Defvar delimiter for dired-copy-filename-as-kill
Date: Tue, 25 May 2021 14:12:02 -0500
I regularly use "dired-copy-filename-as-kill" (by default, it is mapped
to " w") for inserting filenames to the kill ring when being in a dired
buffer.

I'm having the following issue when interacting with filenames that
contain spaces: Because the space is used as the delimiter for the
copied filenames, it is difficult (nearly impossible) to know the
beginning and end of the copied filenames.

I looked at the source code of the function and found that the space
character is hardcoded as the delimiter (see below).

#+BEGIN_SRC emacs-lisp
(defun dired-copy-filename-as-kill (&optional arg)
...
             (mapconcat #'identity
                        (if arg
                            (cond ((zerop (prefix-numeric-value arg))
                                   (dired-get-marked-files))
                                  ((consp arg)
                                   (dired-get-marked-files t))
                                  (t
                                   (dired-get-marked-files
				    'no-dir (prefix-numeric-value arg))))
                          (dired-get-marked-files 'no-dir))
                        " ") ;; <---- [[[ Here's the hardcoded delimiter ]]]
...)
#+END_SRC

I thought that it would be useful to have a defvar that allows
specifying the delimiter for copied filenames through the mentioned
function. Perhaps, its name could be "dired-copy-filename-delimiter".

P.S. This is my first time interacting with this mailing list; forgive
me if I did something wrong.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48657; Package emacs. (Tue, 25 May 2021 19:35:01 GMT) Full text and rfc822 format available.

Message #8 received at 48657 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Rodrigo Morales <moralesrodrigo1100 <at> gmail.com>
Cc: 48657 <at> debbugs.gnu.org
Subject: Re: bug#48657: Defvar delimiter for dired-copy-filename-as-kill
Date: Tue, 25 May 2021 22:34:18 +0300
> From: Rodrigo Morales <moralesrodrigo1100 <at> gmail.com>
> Date: Tue, 25 May 2021 14:12:02 -0500
> 
> (defun dired-copy-filename-as-kill (&optional arg)
> ...
>              (mapconcat #'identity
>                         (if arg
>                             (cond ((zerop (prefix-numeric-value arg))
>                                    (dired-get-marked-files))
>                                   ((consp arg)
>                                    (dired-get-marked-files t))
>                                   (t
>                                    (dired-get-marked-files
> 				    'no-dir (prefix-numeric-value arg))))
>                           (dired-get-marked-files 'no-dir))
>                         " ") ;; <---- [[[ Here's the hardcoded delimiter ]]]
> ...)
> #+END_SRC
> 
> I thought that it would be useful to have a defvar that allows
> specifying the delimiter for copied filenames through the mentioned
> function. Perhaps, its name could be "dired-copy-filename-delimiter".

The only sane value for a reliable delimiter is the null byte, so
maybe it doesn't make much sense to customize it.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48657; Package emacs. (Tue, 25 May 2021 19:45:01 GMT) Full text and rfc822 format available.

Message #11 received at 48657 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Rodrigo Morales <moralesrodrigo1100 <at> gmail.com>, "48657 <at> debbugs.gnu.org"
 <48657 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#48657: Defvar delimiter for
 dired-copy-filename-as-kill
Date: Tue, 25 May 2021 19:44:13 +0000
> Because the space is used as the delimiter for the
> copied filenames, it is difficult (nearly impossible) to know the
> beginning and end of the copied filenames.
> 
> I looked at the source code of the function and found that the space
> character is hardcoded as the delimiter (see below)....
> 
> I thought that it would be useful to have a defvar that allows
> specifying the delimiter for copied filenames through the mentioned
> function. Perhaps, its name could be "dired-copy-filename-delimiter".

Yes.  This was reported by a Dired+ user a while back.
Dired+ fixed it this way, FWIW: Added two defvars, and
updated the command to use one as the separator and the
other to hold the text that's copied to the kill ring.

The second defvar is there so you can obtain the text
even after the kill ring is modified.  For example,
command `diredp-yank-files' uses the value of that var,
not whatever is currently at the head of the kill ring.
And `diredp-move-files-named-in-kill-ring' uses it to
move files to the current dir.

(`dired-yank-files' yanks files to a directory.  It
looks first for files via `interprogram-paste-function',
then it looks in that defvar.)
___

(defvar diredp-last-copied-filenames ()
  "String list of file names last copied to the `kill-ring'.
Copying is done by `dired-copy-filename-as-kill' and related commands.")

(defvar diredp-filename-separator (copy-sequence "\000") ; "^@"
  ;; Should contain only chars that are invalid in a file name.
  "String used to separate file names in a `kill-ring' entry.")





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48657; Package emacs. (Sun, 24 Oct 2021 07:12:02 GMT) Full text and rfc822 format available.

Message #14 received at 48657 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48657 <at> debbugs.gnu.org, Rodrigo Morales <moralesrodrigo1100 <at> gmail.com>
Subject: Re: bug#48657: Defvar delimiter for dired-copy-filename-as-kill
Date: Sun, 24 Oct 2021 00:11:28 -0700
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Rodrigo Morales <moralesrodrigo1100 <at> gmail.com>
>> Date: Tue, 25 May 2021 14:12:02 -0500
>>
>> (defun dired-copy-filename-as-kill (&optional arg)
>> ...
>>              (mapconcat #'identity
>>                         (if arg
>>                             (cond ((zerop (prefix-numeric-value arg))
>>                                    (dired-get-marked-files))
>>                                   ((consp arg)
>>                                    (dired-get-marked-files t))
>>                                   (t
>>                                    (dired-get-marked-files
>> 				    'no-dir (prefix-numeric-value arg))))
>>                           (dired-get-marked-files 'no-dir))
>>                         " ") ;; <---- [[[ Here's the hardcoded delimiter ]]]
>> ...)
>> #+END_SRC
>>
>> I thought that it would be useful to have a defvar that allows
>> specifying the delimiter for copied filenames through the mentioned
>> function. Perhaps, its name could be "dired-copy-filename-delimiter".
>
> The only sane value for a reliable delimiter is the null byte, so
> maybe it doesn't make much sense to customize it.

That's true, but on the other hand replacing space with the null byte as
the hard-coded delimiter for dired-copy-filename-as-kill seems a
bit... clunky.  Even if space sometimes fails, it is not a control
character, which is why I assume that it was chosen.

I've personally never had a problem with using space here, but you
obviously will eventually run into problems.  So I think something
should be done.

I was thinking for a while about allowing a user to set the delimiter
with a prefix command, but then I realized that users might be using
this function *a lot* (I do sometimes) and that UI would quickly get
old.

So perhaps we should just provide the asked for defvar?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48657; Package emacs. (Sun, 24 Oct 2021 12:03:01 GMT) Full text and rfc822 format available.

Message #17 received at 48657 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 48657 <at> debbugs.gnu.org, moralesrodrigo1100 <at> gmail.com
Subject: Re: bug#48657: Defvar delimiter for dired-copy-filename-as-kill
Date: Sun, 24 Oct 2021 15:01:45 +0300
> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Sun, 24 Oct 2021 00:11:28 -0700
> Cc: Rodrigo Morales <moralesrodrigo1100 <at> gmail.com>, 48657 <at> debbugs.gnu.org
> 
> >> I thought that it would be useful to have a defvar that allows
> >> specifying the delimiter for copied filenames through the mentioned
> >> function. Perhaps, its name could be "dired-copy-filename-delimiter".
> >
> > The only sane value for a reliable delimiter is the null byte, so
> > maybe it doesn't make much sense to customize it.
> 
> That's true, but on the other hand replacing space with the null byte as
> the hard-coded delimiter for dired-copy-filename-as-kill seems a
> bit... clunky.

I don't see why.  A number of GNU programs use the null byte as a
reliable delimiter in similar situations (Grep, xargs, etc.), so why
shouldn't we do the same?

> I've personally never had a problem with using space here, but you
> obviously will eventually run into problems.  So I think something
> should be done.

Why using a space when we know it will sometimes fail?  The null byte
will never fail, and Emacs is perfectly capable of handling strings
with embedded null bytes.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48657; Package emacs. (Sun, 24 Oct 2021 12:28:01 GMT) Full text and rfc822 format available.

Message #20 received at 48657 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48657 <at> debbugs.gnu.org, moralesrodrigo1100 <at> gmail.com
Subject: Re: bug#48657: Defvar delimiter for dired-copy-filename-as-kill
Date: Sun, 24 Oct 2021 05:27:51 -0700
Eli Zaretskii <eliz <at> gnu.org> writes:

> I don't see why.  A number of GNU programs use the null byte as a
> reliable delimiter in similar situations (Grep, xargs, etc.), so why
> shouldn't we do the same?

They usually only do so with a special command line argument (e.g. xargs).

> Why using a space when we know it will sometimes fail?  The null byte
> will never fail, and Emacs is perfectly capable of handling strings
> with embedded null bytes.

This is a user facing command, so I think users might run into some
issues with it.  For example, it might just be perceived as ugly.
In the "normal" case, when you deal with file names without spaces in
them, it also just seems more natural to use spaces.

Perhaps we could just detect if any of filenames have spaces in them
and use null byte delimiters if they do?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48657; Package emacs. (Sun, 24 Oct 2021 14:03:02 GMT) Full text and rfc822 format available.

Message #23 received at 48657 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 48657 <at> debbugs.gnu.org, moralesrodrigo1100 <at> gmail.com
Subject: Re: bug#48657: Defvar delimiter for dired-copy-filename-as-kill
Date: Sun, 24 Oct 2021 17:01:37 +0300
> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Sun, 24 Oct 2021 05:27:51 -0700
> Cc: moralesrodrigo1100 <at> gmail.com, 48657 <at> debbugs.gnu.org
> 
> Perhaps we could just detect if any of filenames have spaces in them
> and use null byte delimiters if they do?

Or quote those that do?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48657; Package emacs. (Sun, 24 Oct 2021 14:28:03 GMT) Full text and rfc822 format available.

Message #26 received at 48657 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48657 <at> debbugs.gnu.org, moralesrodrigo1100 <at> gmail.com
Subject: Re: bug#48657: Defvar delimiter for dired-copy-filename-as-kill
Date: Sun, 24 Oct 2021 07:27:19 -0700
Eli Zaretskii <eliz <at> gnu.org> writes:

>> Perhaps we could just detect if any of filenames have spaces in them
>> and use null byte delimiters if they do?
>
> Or quote those that do?

Sure, that's another alternative.  We would need to decide which type of
quoting though, and I guess that will depend on what the user wants this
for.  For example, the quoting rules will be subtly different if the
user wants this for a shell script or for Emacs Lisp.  It seems
non-trivial to me.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48657; Package emacs. (Fri, 15 Jul 2022 10:38:01 GMT) Full text and rfc822 format available.

Message #29 received at 48657 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 48657 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 moralesrodrigo1100 <at> gmail.com
Subject: Re: bug#48657: Defvar delimiter for dired-copy-filename-as-kill
Date: Fri, 15 Jul 2022 12:37:46 +0200
Stefan Kangas <stefan <at> marxist.se> writes:

> Sure, that's another alternative.  We would need to decide which type of
> quoting though, and I guess that will depend on what the user wants this
> for.  For example, the quoting rules will be subtly different if the
> user wants this for a shell script or for Emacs Lisp.  It seems
> non-trivial to me.

I think the best we can get at here is something DWIM-ish -- presumably
the most useful thing here is to do some quoting of files containing
spaces, so I've done that in Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug marked as fixed in version 29.1, send any further explanations to 48657 <at> debbugs.gnu.org and Rodrigo Morales <moralesrodrigo1100 <at> gmail.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Fri, 15 Jul 2022 10:39:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48657; Package emacs. (Fri, 15 Jul 2022 14:18:02 GMT) Full text and rfc822 format available.

Message #34 received at 48657 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Stefan Kangas <stefan <at> marxist.se>
Cc: "48657 <at> debbugs.gnu.org" <48657 <at> debbugs.gnu.org>,
 Eli Zaretskii <eliz <at> gnu.org>,
 "moralesrodrigo1100 <at> gmail.com" <moralesrodrigo1100 <at> gmail.com>
Subject: RE: [External] : bug#48657: Defvar delimiter for
 dired-copy-filename-as-kill
Date: Fri, 15 Jul 2022 14:16:53 +0000
> I think the best we can get at here is something DWIM-ish -- presumably
> the most useful thing here is to do some quoting of files containing
> spaces, so I've done that in Emacs 29.

FWIW, I think the right thing to do is give users
easy control over this (e.g., as I suggested).




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 13 Aug 2022 11:24:08 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 228 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.