From: "Drew Adams" <drew.adams@oracle.com>
To: 7131@debbugs.gnu.org
Subject: bug#7131: 24.0.50; `dired' with cons arg should not ignore arg if buffer exists
Date: Wed, 29 Sep 2010 08:34:17 -0700 [thread overview]
Message-ID: <9165B8BF5E624AAA8F9551E7A82022AF@us.oracle.com> (raw)
(dired '("foo" "file1.c" "file2.c")) opens a Dired buffer named `foo'
with only files file1.c and file2.c. This is a useful feature. The doc
says only that if the arg is a cons then its first element is taken as
the directory name and the rest are the files to list.
But if "foo" is already the name of an existing Dired buffer then that
existing buffer `foo' is simply displayed as it was. The explicit
file-list argument is completely ignored.
Buffer `foo' should instead be updated (its contents replaced) to list
only the files to be included (files in the file-list arg). That is
more useful, and it is anyway easy to recuperate the original Dired
buffer if for some reason the buffer name were a mistake.
The code in question is `dired-internal-noselect'. This code comment
gives the behavior rationale for the case where the Dired buffer
already exists:
;; If there is an existing dired buffer for DIRNAME, just leave
;; buffer as it is (don't even call dired-revert).
;; This saves time especially for deep trees or with ange-ftp.
;; The user can type `g' easily, and it is more consistent with find-file.
;; But if SWITCHES are given they are probably different from the
;; buffer's old value, so call dired-sort-other, which does
;; revert the buffer. A pity we can't possibly do "Directory has
;; changed - refresh? " like find-file does.
(DIRNAME is a typo here BTW - the argument is actually called DIR-OR-LIST,
and if it is a cons then the name is just its car.)
Note the rationale: If SWITCHES are not given, that is, if there was no
expressed intention to change the content of the listing, then just
reuse an existing buffer. But if such an intention was expressed, then
respect it.
Following that rationale, the behavior for a cons arg should be to
respect the explicit file list passed, not to simply ignore it and reuse
an existing buffer.
And since it would be problematic to test the file list for differences
from the existing listing (whether or not it came from a cons arg
previously), we should always just update the buffer to reflect the
file-list that is passed. IOW, with an explicit file list, never reuse
an existing Dired buffer of the same name.
Note that use of a cons as arg is not the typical use, and this use case has
sometimes been forgotten/overlooked when coding, so that there have been several
(recently fixed) bugs because of oversights. I mention this because I imagine
that is the case here: it is not that we intentionally reuse the existing buffer
and ignore the file list. We do that probably only because the coder wasn't
thinking about the cons case. (The DIRNAME typo supports this supposition.)
In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
of 2010-09-20 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags
-Ic:/imagesupport/include'
next reply other threads:[~2010-09-29 15:34 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-29 15:34 Drew Adams [this message]
2017-07-18 11:39 ` bug#7131: 24.0.50; `dired' with cons arg should not ignore arg if buffer exists Tino Calancha
2017-07-21 4:36 ` Tino Calancha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9165B8BF5E624AAA8F9551E7A82022AF@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=7131@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.