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

Previous Next

Full log

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.

Previous Next

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