GNU bug report logs - #79293
[PATCH] Pass dired default filenames via defaults argument

Previous Next

Full log

View this message in rfc822 format

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79293 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: bug#79293: [PATCH] Pass dired default filenames via defaults argument
Date: Sat, 23 Aug 2025 10:58:08 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: 79293 <at> debbugs.gnu.org, juri <at> linkov.net
>> Date: Sat, 23 Aug 2025 17:44:41 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> 
>> > From: Spencer Baugh <sbaugh <at> janestreet.com>
>> > Cc: 79293 <at> debbugs.gnu.org,  juri <at> linkov.net
>> > Date: Sat, 23 Aug 2025 10:40:17 -0400
>> > 
>> > Eli Zaretskii <eliz <at> gnu.org> writes:
>> > >> Cc: Juri Linkov <juri <at> linkov.net>
>> > >> Date: Fri, 22 Aug 2025 17:20:13 -0400
>> > >> From:  Spencer Baugh via "Bug reports for GNU Emacs,
>> > >>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> > >> 
>> > >> Rather than using minibuffer-with-setup-hook and
>> > >> minibuffer-default-add-function, just pass the list of default
>> > >> file names as a regular argument to read-file-name.  This
>> > >> behaves better with various customizations, and also allows the
>> > >> normal abbreviate-file-name logic in read-file-name to run.
>> > >
>> > > "Behaves better" in what sense?
>> > >
>> > > Would you please show examples of commands where the patched version
>> > > behaves better, including the effect of the abbreviate-file-name
>> > > logic?  Because from your OP it is unclear to me what, if any, will be
>> > > the user-facing effects of the new behavior in the relevant Dired
>> > > commands.
>> > 
>> > Both before and after my change:
>> > 
>> > 1. M-: (read-file-name ":" nil (expand-file-name "~"))
>> > 2. M-n
>> > 3. Observe ~/ in the minibuffer
>> > 
>> > This is because read-file-name calls abbreviate-file-name on the default
>> > argument.
>> > 
>> > Before my change:
>> > 
>> > 1. C-x C-f ~/
>> > 2. R (or Y or H)
>> > 3. M-n
>> > 4. Observe the minibuffer starts with /home/user
>> > 
>> > After my change:
>> > 
>> > 1. C-x C-f ~/
>> > 2. R (or Y or H)
>> > 3. M-n
>> > 4. Observe the minibuffer starts with ~/ as usual for read-file-name
>> 
>> So abbreviate-file-name is the only improvement provided by your
>> patch?  Your OP seemed to imply that there were others:
>
> Btw, I don't quite follow your recipes.  What does R (or Y or H) do in
> this sequence:
>
>> 1. C-x C-f ~/
>> 2. R (or Y or H)
>> 3. M-n
>> 4. Observe the minibuffer starts with /home/user
>
> In my case these are self-inserting characters, so after step 2 I have
> "Find file: ~/R" in the minibuffer.  And then M-n signals an error.
> is something missing from the recipe?

Er, yes, it should be:
1. C-x C-f ~/ RET
(just missing a trailing RET)

> Btw, in my case, this recipe:
>
>> 1. M-: (read-file-name ":" nil (expand-file-name "~"))
>> 2. M-n
>> 3. Observe ~/ in the minibuffer
>
> produces "~" in the minibuffer, not "~/".  Again, is something missing
> from the recipe?

No, just a typo, indeed it produces just "~".  Same difference either
way: the point is just to demonstrate that read-file-name calls
abbreviate-file-name on DEFAULT-FILENAME.

Previous Next

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