Subject: bug#7131: closed (Re: bug#7131: 24.0.50; `dired' with cons arg should not ignore arg if buffer exists)

From: [email-masked] (GNU bug Tracking System)
Date: Fri, 21 Jul 2017 04:37:02 +0000

Your bug report

#7131: 24.0.50; `dired' with cons arg should not ignore arg if buffer exists

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
7131: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7131
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#7131: 24.0.50; `dired' with cons arg should not ignore arg if buffer exists
From: Tino Calancha <[email-masked]>
To: [email-masked]
Date: Fri, 21 Jul 2017 13:36:34 +0900
List-Id: <debbugs-submit.debbugs.gnu.org>

>> 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.
> IMO, if `dired-directory' is a cons and DIR-OR-LIST is a string then we
> must update the buffer as well: in this case, the user want to see the
> full listing of that directory.
Fixed in master branch as commit 1d559e384b467b3f74e8b78695f124b561c884d9

Subject: 24.0.50; `dired' with cons arg should not ignore arg if buffer exists
From: "Drew Adams" <[email-masked]>
To: <[email-masked]>
Date: Wed, 29 Sep 2010 08:34:17 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

(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'