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

Previous Next

To reply to this bug, email your comments to 77668 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kasper Gałkowski <kpg <at> posteo.net>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Consider the current subdirectory in 'dired-create-empty-file'
Date: Wed, 09 Apr 2025 03:29:42 +0000

[Message part 1 (text/plain, inline)]

Tags: patch


Dear developers,

This small patch changes the 'dired-create-empty-file' command to use
the currently focused/active subdirectory - rather than the
topmost/default one - as the starting dirname for the interactive
prompt. This makes it consistent with 'dired-create-directory'.

Cheers,

  Kasper


In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.48, cairo version 1.18.2)
Windowing system distributor 'The X.Org Foundation', version 11.0.12101016
System Description: NixOS 24.11 (Vicuna)

Configured using:
 'configure
 --prefix=/nix/store/79wgzibx44pyybla0p6x2l5mqa34688w-emacs-tip
 --bindir=/nix/store/79wgzibx44pyybla0p6x2l5mqa34688w-emacs-tip/bin
 --sbindir=/nix/store/79wgzibx44pyybla0p6x2l5mqa34688w-emacs-tip/sbin
 --includedir=/nix/store/79wgzibx44pyybla0p6x2l5mqa34688w-emacs-tip/include
 --mandir=/nix/store/79wgzibx44pyybla0p6x2l5mqa34688w-emacs-tip/share/man
 --infodir=/nix/store/nhawn00yywb6py7yzmz8xgrpz5wg32w3-emacs-tip-info/share/info
 --docdir=/nix/store/79wgzibx44pyybla0p6x2l5mqa34688w-emacs-tip/share/doc/emacs
 --libdir=/nix/store/79wgzibx44pyybla0p6x2l5mqa34688w-emacs-tip/lib
 --libexecdir=/nix/store/79wgzibx44pyybla0p6x2l5mqa34688w-emacs-tip/libexec
 --localedir=/nix/store/79wgzibx44pyybla0p6x2l5mqa34688w-emacs-tip/share/locale
 --disable-gc-mark-trace --disable-build-details --without-sound
 --without-native-compilation --with-x --with-x-toolkit=gtk3
 --with-modules --with-threads'

[0001-Consider-the-current-subdirectory-in-dired-create-em.patch (text/patch, attachment)]

Message #8 received at 77668 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kasper Gałkowski <kpg <at> posteo.net>
Cc: 77668 <at> debbugs.gnu.org
Subject: Re: bug#77668: [PATCH] Consider the current subdirectory in
 'dired-create-empty-file'
Date: Wed, 09 Apr 2025 15:54:34 +0300

> From: Kasper Gałkowski <kpg <at> posteo.net>
> Date: Wed, 09 Apr 2025 03:29:42 +0000
> 
> This small patch changes the 'dired-create-empty-file' command to use
> the currently focused/active subdirectory - rather than the
> topmost/default one - as the starting dirname for the interactive
> prompt. This makes it consistent with 'dired-create-directory'.

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.

Message #11 received at 77668 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kasper Gałkowski <kpg <at> posteo.net>
Cc: 77668 <at> debbugs.gnu.org
Subject: Re: bug#77668: [PATCH] Consider the current subdirectory in
 'dired-create-empty-file'
Date: Fri, 11 Apr 2025 12:24:35 +0300

> Date: Fri, 11 Apr 2025 08:58:46 +0000
> Cc: 77668 <at> debbugs.gnu.org
> From: Kasper Gałkowski <kpg <at> 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.  That's what I
would expect users to expect.

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.

Thanks.

Message #14 received at 77668 <at> debbugs.gnu.org (full text, mbox):

From: Kasper Gałkowski <kpg <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77668 <at> debbugs.gnu.org
Subject: Re: bug#77668: [PATCH] Consider the current subdirectory in
 'dired-create-empty-file'
Date: Fri, 11 Apr 2025 08:58:46 +0000

> 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?

I suspect not many people use dired-insert-subdir (just based on the
observation that, for many years, the popular diff-hl dired extension
highlights VC states for the default-directory, i.e. just the topmost 
subdir).

It might have been that the first one to write d-c-e-f wasn't a user of 
d-i-s,
so the case of those two's interop flew under the radar, at that time.

On the other hand, the older dired-create-directory *is* subdir aware. This
makes sense, because according to the Git log, its author is also the author
of d-i-s.

It's quite a contrast between those two. Let's say one opens dired (C-x d),
inserts some subdirs (i), creates a directory deep down here (+). Now, tries
to dired-create-empty-file, but the file is created back up above.

If this default were to be changed, do you think it could have an impact on
dired's out of the box intuitiveness?

How would the average user expect for the above scenario to work?

Could creating an empty file in the topmost directory, rather than the one
around point, be done instead by using dired-goto-subdir first? (Maybe that
could be how it works with C-u).

-- 
  Kasper

Message #17 received at 77668 <at> debbugs.gnu.org (full text, mbox):

From: Kasper Gałkowski <kpg <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77668 <at> debbugs.gnu.org
Subject: Re: bug#77668: [PATCH] Consider the current subdirectory in
 'dired-create-empty-file'
Date: Sat, 12 Apr 2025 16:25:25 +0000

I hoped that consolidating these two commands would be a quick win, but
I understand that could go wrong in unexpected ways.

Still, there have been a couple of breaking changes in the 30.1 release.
For example, to gdb-many-windows, eshell, eldoc and IELM. So, there must
be conditions under which such risk is worth the weight.

Maybe I should have studied the bugs/tickets related to these before
creating this one in order to present a more convincing argument.

> So I think adding this as an optional behavior a good compromise.

Myself I've wrapped the command in a defun with a different interactive
spec. To me, it seems a less invasive soultion, because it requires no
changes to the official sources - esp. given the change is so small.

Cheers,

-- 
  Kasper

Previous Next

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