bug#24184: 25.0.94; dired-copy-filename-as-kill does not quote or properly separate file names

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#24184: 25.0.94; dired-copy-filename-as-kill does not quote or properly separate file names

Gereon Kaiping
Enhancement Request:

> Start emacs
> Find a directory containing more than one file with space in the file
> name, opening that directory in dired
> Mark more than one file, eg. using `m`
> Run 'dired-copy-filename-as-kill for example by pressing `w`
> Notice that there is no difference between the space separating file
> names and the spaces in file names

$ touch "this file" "that file"
$ emacs -Q
C-x C-f RET m m w

gives

that file this file

but should give something like

"that file" "this file"

or

that file
this file

to be much more useful. The former looks cleanest, because then the
content can be yanked as elisp list, but would of course require that
not only filenames are quoted, but that also " be quoted inside file
names.

--
Gereon



Reply | Threaded
Open this post in threaded view
|

bug#24184: 25.0.94; dired-copy-filename-as-kill does not quote or properly separate file names

Lars Ingebrigtsen
Gereon Kaiping <[hidden email]> writes:

> $ touch "this file" "that file"
> $ emacs -Q
> C-x C-f RET m m w
>
> gives
>
> that file this file
>
> but should give something like
>
> "that file" "this file"
>
> or
>
> that file
> this file
>
> to be much more useful. The former looks cleanest, because then the
> content can be yanked as elisp list, but would of course require that
> not only filenames are quoted, but that also " be quoted inside file
> names.

Hm...  I guess that depends on what the purpose of the copy-as-kill is.
In the single file case, we probably don't want to quote "this file"
because then we can't use that to yank it into the file prompt, for
instance.

But in the several-file case, we can't use it for that anyway, and then
quoting these file names is probably better than not.

Hm...

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



Reply | Threaded
Open this post in threaded view
|

bug#24184: 25.0.94; dired-copy-filename-as-kill does not quote or properly separate file names

Juri Linkov-2
>> $ touch "this file" "that file"
>> $ emacs -Q
>> C-x C-f RET m m w
>>
>> gives
>>
>> that file this file
>>
>> but should give something like
>>
>> "that file" "this file"
>>
>> or
>>
>> that file
>> this file
>>
>> to be much more useful. The former looks cleanest, because then the
>> content can be yanked as elisp list, but would of course require that
>> not only filenames are quoted, but that also " be quoted inside file
>> names.
>
> Hm...  I guess that depends on what the purpose of the copy-as-kill is.
> In the single file case, we probably don't want to quote "this file"
> because then we can't use that to yank it into the file prompt, for
> instance.
>
> But in the several-file case, we can't use it for that anyway, and then
> quoting these file names is probably better than not.

I think filenames should be quoted only when really necessary.  IOW,
only if (not (equal (shell-quote-argument "this file") "this file"))
but not when (equal (shell-quote-argument "this-file") "this-file").



Reply | Threaded
Open this post in threaded view
|

bug#24184: 25.0.94; dired-copy-filename-as-kill does not quote or properly separate file names

Drew Adams
> I think filenames should be quoted only when really necessary.  IOW,
> only if (not (equal (shell-quote-argument "this file") "this file"))
> but not when (equal (shell-quote-argument "this-file") "this-file").

Even stronger than that.  There is no reason to suppose
that everyone wants to yank the text only in contexts
where it should be double-quoted.

On the contrary.  People have been usefully yanking it
and using it without quotes for decades.  This is a useful,
longstanding Emacs feature.

If someone wants a different copy or paste or both behavior
then s?he can define a new command and bind a key to it.

If someone thinks that Emacs itself needs such a command
and key then s?he can propose it.  But there is zero reason
to co-opt this fine feature by replacing it by something else.