Subject: Re: bug#76792: [PATCH] dired-copy-filename-as-kill to support project relative names

From: Dmitry Gutov <[email-masked]>
Date: Sat, 8 Mar 2025 04:48:25 +0200

On 07/03/2025 18:20, Stefan Kangas wrote:
> Dmitry Gutov <[email-masked]> writes:
> 
>> On 07/03/2025 09:06, Eli Zaretskii wrote:
>>> Using 1 as the prefix arg which means files are relative to project
>>> root seems inconsistent with the meaning of zero argument.
>>
>> Is it really? We have 0 which means "absolute name" and we have 'C-u'
>> (which often translates to 4) which means "only base name".
>>
>> The project-relative name sits somewhere in the middle (when judging by
>> length, for example) so 1 seems fitting.
>>
>>> So I would
>>> suggest to use "C-u C-u" for the new meaning.  It is not harder to
>>> type, and it is more mentally similar to "just C-u".
>>
>> I could agree to 'C-u C-u' as well, but it does seem like a longer
>> sequence requiring two hands (while '1' sits very close to 'w' and would
>> be typed with one hand).
> 
> FWIW, on some keyboard layouts, e.g. Dvorak which I have here, this
> doesn't hold.  :-)

True, and anyway I think semantic fit is more important.

>> Semantically as well the new behavior doesn't
>> seem like an advanced version of the current 'C-u' behavior.
>>
>> But if the majority prefers 'C-u C-u', I won't argue.
> 
> Hmm, `dired-copy-filename-as-kill` with prefix 1 copies one file, with
> prefix 2 copies two, with 3 copies three, and so on.
> 
> Do we care to keep this behavior?

I actually wasn't aware of this one.

Like you concluded, it would still be supported, except for value ARG=1. 
We have reserved ARG=0 for a different behavior already, so it seems 
that ARG is not suitable for programmatic calculation anyway.