GNU bug report logs - #76792
[PATCH] dired-copy-filename-as-kill to support project relative names

Previous Next

Package: emacs;

Reported by: Dmitry Gutov <dmitry <at> gutov.dev>

Date: Thu, 6 Mar 2025 22:40:02 UTC

Severity: wishlist

Tags: patch

Fixed in version 31.1

Done: Dmitry Gutov <dmitry <at> gutov.dev>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Stefan Kangas <stefankangas <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 76792 <at> debbugs.gnu.org
Subject: bug#76792: [PATCH] dired-copy-filename-as-kill to support project relative names
Date: Sat, 8 Mar 2025 04:48:25 +0200
On 07/03/2025 18:20, Stefan Kangas wrote:
> Dmitry Gutov <dmitry <at> gutov.dev> 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.




This bug report was last modified 120 days ago.

Previous Next


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