From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: dired with cons arg: behavior when Dired buffer named already exists Date: Mon, 27 Sep 2010 10:20:18 -0700 Message-ID: <97034BF98C6A4B8CAF6FC8765D9CB5F2@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1285608096 1849 80.91.229.12 (27 Sep 2010 17:21:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 27 Sep 2010 17:21:36 +0000 (UTC) To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 27 19:21:35 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1P0HOQ-0007we-Qm for ged-emacs-devel@m.gmane.org; Mon, 27 Sep 2010 19:21:35 +0200 Original-Received: from localhost ([127.0.0.1]:46992 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P0HOQ-0003Un-9D for ged-emacs-devel@m.gmane.org; Mon, 27 Sep 2010 13:21:34 -0400 Original-Received: from [140.186.70.92] (port=40117 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P0HOL-0003Tb-9C for emacs-devel@gnu.org; Mon, 27 Sep 2010 13:21:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1P0HOJ-0002d6-T4 for emacs-devel@gnu.org; Mon, 27 Sep 2010 13:21:29 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:27295) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P0HOJ-0002cp-O1 for emacs-devel@gnu.org; Mon, 27 Sep 2010 13:21:27 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o8RHLLWR032273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 27 Sep 2010 17:21:23 GMT Original-Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o8RHLKYt005346 for ; Mon, 27 Sep 2010 17:21:20 GMT Original-Received: from abhmt015.oracle.com by acsmt353.oracle.com with ESMTP id 633878861285608018; Mon, 27 Sep 2010 10:20:18 -0700 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 27 Sep 2010 10:20:17 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: ActeaEG3S7W0QieiSUiM8ZIy1mNmUg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:131011 Archived-At: (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 what should happen if "foo" is already the name of an existing Dired buffer? What does happen is that the existing Dired buffer `foo' is simply displayed. That is, the explicit file list is completely ignored. Wouldn't it be better if buffer `foo' were updated to list only the included files? That would be more useful, and it is certainly easy to recuperate the original Dired buffer if for some reason the buffer name was a mistake. The code in question is `dired-internal-noselect'. This 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 - 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. WDOT? 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.)