bug#77668: [PATCH] Consider the current subdirectory in 'dired-create-empty-file'

[Stephen Berman]

On Fri, 11 Apr 2025 12:24:35 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> Date: Fri, 11 Apr 2025 08:58:46 +0000
>> Cc: 77668@debbugs.gnu.org
>> From: Kasper Gałkowski <kpg@posteo.net>
>> 
>>  > Thanks, but I don't think we can make such backward-incompatible
>>  > behavior change to be the default.  We could make it optional
>>  > behavior, like if the command is invoked with a prefix argument, or
>>  > have it controlled by a new user option, which will by default be off.
>> 
>> I understand that you are skeptical about changing the command in an
>> incompatible way - esp. with the software having this many users.
>> 
>> Let's dive a bit deeper: who would the change break? How inconvenient would
>> that be for them?
>
> Bitter experience has taught us that we have no real means of
> answering such questions.  Our own logic and assumptions do not
> necessarily reflect those of the Emacs users out there.  And there are
> always use cases we cannot imagine.
>
> At face value, this command should do what its name and doc string
> say: create an empty file in this buffer's directory.

The command can in fact do more than that and then the doc string is at
best misleading; here it is:

"Create an empty file called FILE.
Add a new entry for the new file in the Dired buffer.
Parent directories of FILE are created as needed.
If FILE already exists, signal an error."

If the current buffer D is a Dired buffer and you invoke
dired-create-empty-file to create an empty file F in D, then indeed, the
entry for F is added to D.  But if you use the command to create F in a
previously non-existing subdirectory S of D, then the entry for S, not
F, is added to D, so the doc string, taken literally, is wrong in this
case (F is of course added to S, but S is not currently a Dired buffer).

>                                                        That's what I
> would expect users to expect.

For the subdirectory case I think it is not so clear what users would
expect; the doc string might lead them to expect that a new Dired buffer
S containing F would be opened.

> So making such incompatible changes in the default behavior is not
> something we can do.  If it's an opt-in behavior, it should support
> your needs (after you customize the option to your liking) and also
> avoid breaking anyone who wants the previous behavior.  So I think
> adding this as an optional behavior a good compromise.

Given that the current behavior has existed since the command was
introduced (see bug#24150), I agree it should not be unconditionally
changed.  However, the discussion in bug#24150 makes no mention of the
inserted subdirectory use case, so I also agree with Kasper that this
was probably an oversight.  This conclusion is further supported by the
fact that in the bug thread no justification is given for omitting the
call to dired-current-directory as the DIR argument of the
read-file-name invocation in dired-create-empty-file, although
dired-create-directory (which has this argument) was the explicit model
for dired-create-empty-file.

Kasper's proposal to amend this omission in fact introduces a further
incompatibility: it makes invoking dired-create-empty-file outside of a
Dired buffer raise an error, just as invoking dired-create-directory
outside of Dired does.  However, I don't think this is a serious
incompatibility, because the command make-empty-file (which
dired-create-empty-file uses) exists precisely for this purpose.

In short, I support Kasper's proposal, but agree with Eli that, given
the existing behavior, it should be conditioned on a user option.  If
Kasper does not want to submit a patch for that, I'd be happy to do so.

Steve Berman