GNU bug report logs -
#67856
Dired navigation via directory line does not respect dired-kill-when-opening-new-dired-buffer
Previous Next
Reported by: Jared Finder <jared <at> finder.org>
Date: Sat, 16 Dec 2023 20:36:01 UTC
Severity: normal
Tags: patch
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #18 received at 67856-done <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 24 Dec 2023 12:11:49 -0800
> From: Jared Finder <jared <at> finder.org>
> Cc: 67856 <at> debbugs.gnu.org
>
> On 2023-12-21 05:18, Eli Zaretskii wrote:
> >> Date: Sat, 16 Dec 2023 12:35:10 -0800
> >> From: Jared Finder via "Bug reports for GNU Emacs,
> >> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >>
> >> The option dired-kill-when-opening-new-dired-buffer is not respected
> >> when clicking on parent directories in the directory line at the top
> >> of dired buffers. This can be fixed by calling
> >> dired--find-possibly-alternate-file instead of dired in the
> >> callback, as my attached patch does.
> >>
> >> I believe changing to dired--find-possibly-alternate-file is safe
> >> because from playing around with dired, the directory being clicked
> >> on must be a directory and can not contain wildcards at this point.
> >> Therefore, at this point it is known that the directory is just a
> >> plain directory (no wildcards) and so going through find-file
> >> machinery will have the intended result.
> >
> > If we want to install this on the emacs-29 release branch, I'd prefer
> > a safer variant, which actually verified that we don't call
> > dired--find-possibly-alternate-file with a wildcard. That's because
> > we have quite a few features that place buffers in Dired mode, and we
> > could easily miss one that does have wildcards there.
> >
> > So would you mind modifying the patch a little so that it checks
> > whether current-dir includes wildcards, and if so, calls 'dired'
> > instead of dired--find-possibly-alternate-file?
>
> Done, new patch attached. Luckily, there already is a function that
> does exactly the right check.
>
> Feel free to alter the comment explaining why this third code path
> exists. I wasn't sure the right style to indicate this type of
> defensive code path that I am not certain is needed.
Thanks, installed on the emacs-29 branch with some minor reformatting,
and closing the bug.
This bug report was last modified 1 year and 152 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.