From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Antoine Levitt" Newsgroups: gmane.emacs.devel Subject: Re: [Patch] Behavior of dired when there already is a dired buffer of the same directory Date: Tue, 2 Sep 2008 16:00:05 +0200 Message-ID: <6fa54e4e0809020700p1ff4497ey7bd80be670c975d1@mail.gmail.com> References: <6fa54e4e0808311550p7b2524dbg8c903904a09d4474@mail.gmail.com> <87prnohfcw.fsf@catnip.gol.com> <6fa54e4e0808311753j3cef9618k514ef0691b2e6d5d@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9653_7076184.1220364005737" X-Trace: ger.gmane.org 1220364058 17433 80.91.229.12 (2 Sep 2008 14:00:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 2 Sep 2008 14:00:58 +0000 (UTC) Cc: emacs-devel@gnu.org, Stefan Monnier , miles@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 02 16:01:51 2008 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.50) id 1KaWRV-00073f-TH for ged-emacs-devel@m.gmane.org; Tue, 02 Sep 2008 16:01:14 +0200 Original-Received: from localhost ([127.0.0.1]:32979 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KaWQW-0000zr-R8 for ged-emacs-devel@m.gmane.org; Tue, 02 Sep 2008 10:00:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KaWQS-0000zK-7O for emacs-devel@gnu.org; Tue, 02 Sep 2008 10:00:08 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KaWQR-0000z4-Oc for emacs-devel@gnu.org; Tue, 02 Sep 2008 10:00:07 -0400 Original-Received: from [199.232.76.173] (port=48267 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KaWQR-0000z1-J2 for emacs-devel@gnu.org; Tue, 02 Sep 2008 10:00:07 -0400 Original-Received: from ey-out-1920.google.com ([74.125.78.147]:34091) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KaWQQ-0000OZ-Td for emacs-devel@gnu.org; Tue, 02 Sep 2008 10:00:07 -0400 Original-Received: by ey-out-1920.google.com with SMTP id 4so937318eyg.24 for ; Tue, 02 Sep 2008 07:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=JmNT4p4PM04+x+uvCmATzfaulf+37jpd2ObYm4IgsGs=; b=FDVEIVEsfkQ97JX/FiinUZJezHh4yM0dt2J4SzyclvjnCy/DrY7ly6F5WXOZqJnjAZ H5ISnx6LxVQiqK0fs0/aFWjihzw8epIgd7X2k5N5WV7Wzjh9bCNcUL0B+ZfV5+J/A8DD DgI1I4nSJwCcE7Yj/vvgCZKjwVxRPKFQGz7+c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=HpF+PmcsaXf/IDAgSWWdLKgvHAsvWAL2HouD7R53jgM4LNRka/gRj7Rl7VrYuRtEXy 9U3XAL2ENkDW/Ytm/l0nj4Z4IRJeyKxnd0xHq8pvGOoS/kSfpkza5a23K9ox12aCVG9T tSDTkSzlM4a6TrgHg30Evqv9qrIuE0P5rkTL0= Original-Received: by 10.210.27.20 with SMTP id a20mr8334886eba.86.1220364005741; Tue, 02 Sep 2008 07:00:05 -0700 (PDT) Original-Received: by 10.210.141.18 with HTTP; Tue, 2 Sep 2008 07:00:05 -0700 (PDT) In-Reply-To: X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) 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:103419 Archived-At: ------=_Part_9653_7076184.1220364005737 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline In retrospect, I agree with you all. I'm sorry I have not thought things through before posting. In any case, the comment in CVS dired.el, L733 is misleading. On another unrelated note, kudos to those who changed the default behavior of C-n C-p in case where one logical line is displayed on multiple visual lines. This has bugged me for some time now, and I think the default behavior is much more sensible now. ( I still think the default behavior for scrolling is insane, though, but I guess there are reasons to that, and I don't want to start a troll :) ) Keep up the great work ! 2008/9/2 Richard M. Stallman > > In general, prompting the user for optional information is a bad idea, > > and this is especially true for "asynchronous" events. > > I agree, but it's also true that we do exactly that for plain files, > which is a much more common case, so this same argument would call for > a similar change to plain files. > > Plain files are less likely to change while you have them visited. > If they do, continuing to edit the old contents is probably a grave > mistake. > > Precisely because this is a rather grave occurrence, > it would be a mistake to revert without telling the user. > Asking the user the question of whether to revert is an ideal > way to inform the user of the anomaly. > > Directories often change while you have them in Dired, and that is not > an anomaly. Continuing to operate on the Dired buffer is probably ok. > Reverting it automatically would be ok, but it is too slow. > I think the message now used is just the right behavior. > ------=_Part_9653_7076184.1220364005737 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
In retrospect, I agree with you all. I'm sorry I have not thought things through before posting.
In any case, the comment in CVS dired.el, L733 is misleading.
On another unrelated note, kudos to those who changed the default behavior of C-n C-p in case where one logical line is displayed on multiple visual lines. This has bugged me for some time now, and I think the default behavior is much more sensible now.
( I still think the default behavior for scrolling is insane, though, but I guess there are reasons to that, and I don't want to start a troll :) )
Keep up the great work !
2008/9/2 Richard M. Stallman <rms@gnu.org>
   > In general, prompting the user for optional information is a bad idea,
   > and this is especially true for "asynchronous" events.

   I agree, but it's also true that we do exactly that for plain files,
   which is a much more common case, so this same argument would call for
   a similar change to plain files.

Plain files are less likely to change while you have them visited.
If they do, continuing to edit the old contents is probably a grave mistake.

Precisely because this is a rather grave occurrence,
it would be a mistake to revert without telling the user.
Asking the user the question of whether to revert is an ideal
way to inform the user of the anomaly.

Directories often change while you have them in Dired, and that is not
an anomaly.  Continuing to operate on the Dired buffer is probably ok.
Reverting it automatically would be ok, but it is too slow.
I think the message now used is just the right behavior.

------=_Part_9653_7076184.1220364005737--