bug#48657: Defvar delimiter for dired-copy-filename-as-kill

bug#48657: Defvar delimiter for dired-copy-filename-as-kill

[Rodrigo Morales]

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.

bug#48657: Defvar delimiter for dired-copy-filename-as-kill

[Eli Zaretskii]

> From: Rodrigo Morales <moralesrodrigo1100@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.

bug#48657: [External] : bug#48657: Defvar delimiter for dired-copy-filename-as-kill

[Drew Adams]

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

bug#48657: Defvar delimiter for dired-copy-filename-as-kill

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Rodrigo Morales <moralesrodrigo1100@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?

bug#48657: Defvar delimiter for dired-copy-filename-as-kill

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sun, 24 Oct 2021 00:11:28 -0700
> Cc: Rodrigo Morales <moralesrodrigo1100@gmail.com>, 48657@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.

bug#48657: Defvar delimiter for dired-copy-filename-as-kill

[Stefan Kangas]

Eli Zaretskii <eliz@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?

bug#48657: Defvar delimiter for dired-copy-filename-as-kill

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sun, 24 Oct 2021 05:27:51 -0700
> Cc: moralesrodrigo1100@gmail.com, 48657@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?

bug#48657: Defvar delimiter for dired-copy-filename-as-kill

[Stefan Kangas]

Eli Zaretskii <eliz@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.

bug#48657: Defvar delimiter for dired-copy-filename-as-kill

[Lars Ingebrigtsen]

Stefan Kangas <stefan@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#48657: Defvar delimiter for dired-copy-filename-as-kill

[Drew Adams]

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