[Patch] Behavior of dired when there already is a dired buffer of the same directory

[Patch] Behavior of dired when there already is a dired buffer of the same directory

[Antoine Levitt]

[-- Attachment #1: Type: text/plain, Size: 3695 bytes --]

Hi,
If I have a dired open on x, do external modifications on the structure of
x, and rerun dired on x, emacs currently advises me to press g to revert the
buffer. This is inefficient, and I'd much rather be offered to revert by a
y/n prompt. The relevant function includes the commentary :
;; A pity we can't possibly do "Directory has changed - refresh? "
;; like find-file does.
cvs annotate attributes this to Richard Stallman, in 1992. I didn't find the
reason why that was impossible. I contribute this patch in the hope that
this comment was motivated by technical difficulties that no longer exist.
It creates a new setting, dired-refresh-modified-dirs, which controls the
behavior, and defaults to ask the user by y-or-no-p.
I tested it, and found no flaws. I am still not sure about a few points,
notably switches : whether to reset the switches after a new invocation of
dired, for instance.
I have not much experience in elisp, much less in dired, but I still hope
this patch to be relevant. If it's not, feel free to disregard it.
Antoine Levitt


Here is the patch to dired.el against current CVS :
--- emacs/emacs/lisp/dired.el    2008-08-23 10:01:36.000000000 +0200
+++ /usr/share/emacs/23.0.60/lisp/dired.el    2008-09-01 00:42:55.000000000
+0200
@@ -168,6 +168,18 @@
   :type 'boolean
   :group 'dired)

+;;;###autoload
+(defcustom dired-refresh-modified-dirs 'ask
+  "*Controls the behavior of dired when invoked on a directory
+that already has a dired buffer.
+If t, always refresh.
+If ask, ask user.
+If nil, never refresh"
+  :type '(choice (const :tag "Refresh" t)
+         (const :tag "Ask user" ask)
+         (const :tag "Don't refresh" nil))
+  :group 'dired)
+
 ; These variables were deleted and the replacements are on files.el.
 ; We leave aliases behind for back-compatibility.
 (defvaralias 'dired-free-space-program 'directory-free-space-program)
@@ -723,15 +735,11 @@
      (dired-directory-changed-p dirname))))

 (defun dired-internal-noselect (dir-or-list &optional switches mode)
-  ;; 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.
+  ;; If there is an existing dired buffer for DIRNAME, decide whether
+  ;; to revert or not based on the customizable variable
+  ;; dired-refresh-modified-dirs. Note that when switches are passed
+  ;; to this function, it is always assumed that the buffer has to be
+  ;; reverted
   ;; Optional argument MODE is passed to dired-find-buffer-nocreate,
   ;; see there.
   (let* (dirname
@@ -760,9 +768,15 @@
            (dired-sort-other switches))
           ;; If directory has changed on disk, offer to revert.
           ((when (dired-directory-changed-p dirname)
-         (message "%s"
-              (substitute-command-keys
-               "Directory has changed on disk; type \\[revert-buffer] to
update Dired")))))
+         (case dired-refresh-modified-dirs
+           (nil nil)
+           ('ask
+            (when (y-or-n-p "Directory has changed on disk. Refresh?")
+              (dired-revert)))
+           (t
+            (dired-revert)
+            (message
+             "Directory has changed on disk. Buffer refreshed."))))))
       ;; Else a new buffer
       (setq default-directory
         ;; We can do this unconditionally

[-- Attachment #2: Type: text/html, Size: 5187 bytes --]

Re: [Patch] Behavior of dired when there already is a dired buffer of the same directory

[Lennart Borgman (gmail)]

Antoine Levitt wrote:
> Hi,
> If I have a dired open on x, do external modifications on the structure
> of x, and rerun dired on x, emacs currently advises me to press g to
> revert the buffer. This is inefficient, and I'd much rather be offered
> to revert by a y/n prompt. The relevant function includes the commentary :
> ;; A pity we can't possibly do "Directory has changed - refresh? "
> ;; like find-file does.
> cvs annotate attributes this to Richard Stallman, in 1992. I didn't find
> the reason why that was impossible. I contribute this patch in the hope
> that this comment was motivated by technical difficulties that no longer
> exist. It creates a new setting, dired-refresh-modified-dirs, which
> controls the behavior, and defaults to ask the user by y-or-no-p.
> I tested it, and found no flaws. I am still not sure about a few points,
> notably switches : whether to reset the switches after a new invocation
> of dired, for instance.
> I have not much experience in elisp, much less in dired, but I still
> hope this patch to be relevant. If it's not, feel free to disregard it.
> Antoine Levitt


I see no reason why the default should not be that the dired buffers are
just refreshed (with an idle timer and a hook if the user tries to use
them first).

Re: [Patch] Behavior of dired when there already is a dired buffer of the same directory

[Mathias Dahl]

> I see no reason why the default should not be that the dired buffers are
> just refreshed (with an idle timer and a hook if the user tries to use
> them first).

For me, that would be very annoying. I often use Dired to open folders
on Windows network shares, shares that might be in remote locations.
Having Emacs auto refresh now and then would lock it up for several
seconds each time.

I have no problem hitting `g' once in a while.

Another case against it, maybe even a better one: If you are, like me,
using the toggle and kill commands in Dired buffers, maybe together
with % m and % g, you would be really angry if you lost a surgically
selected batch of files because the buffer was refreshed.

m

Re: [Patch] Behavior of dired when there already is a dired buffer of the same directory

[David House]

2008/9/1 Mathias Dahl <mathias.dahl@gmail.com>:
> Another case against it, maybe even a better one: If you are, like me,
> using the toggle and kill commands in Dired buffers, maybe together
> with % m and % g, you would be really angry if you lost a surgically
> selected batch of files because the buffer was refreshed.

I see no reason to lose marks on a buffer refresh, unless you marked a
file which no longer exists (which is presumably the right thing to do
anyway, since you can't do anything with that file).

-- 
-David

Re: [Patch] Behavior of dired when there already is a dired buffer of the same directory

[Miles Bader]

"Antoine Levitt" <smeuuh@gmail.com> writes:
> If I have a dired open on x, do external modifications on the structure of
> x, and rerun dired on x, emacs currently advises me to press g to revert the
> buffer. This is inefficient, and I'd much rather be offered to revert by a
> y/n prompt.

How exactly is typing "y" any more efficient than typing "g"?

[It's certainly the case, though that typing nothing is more efficient
than typing "n"...]

-Miles

-- 
Selfish, adj. Devoid of consideration for the selfishness of others.

Re: [Patch] Behavior of dired when there already is a dired buffer of the same directory

[Antoine Levitt]

[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]

> If I have a dired open on x, do external modifications on the structure of

> > x, and rerun dired on x, emacs currently advises me to press g to revert
> the
> > buffer. This is inefficient, and I'd much rather be offered to revert by
> a
> > y/n prompt.
>
> How exactly is typing "y" any more efficient than typing "g"?
>
> [It's certainly the case, though that typing nothing is more efficient
> than typing "n"...]
>
> -Miles
>
> --
> Selfish, adj. Devoid of consideration for the selfishness of others.


That's a good point. However, the user is clearly offered a choice, and I
think it would be better if this choice was made explicit by a question,
rather than just a suggestion, particularly given the fact that this
situation is not so common (a user that direds to an existing dired probably
doesn't expect that there's already a dired buffer open). My choice of word
was poor : it's not more efficient, but clearer and more coherent with the
way other emacs programs work (at least I think so, but I'm by no means an
expert)

>I see no reason why the default should not be that the dired buffers are
>just refreshed (with an idle timer and a hook if the user tries to use
>them first).

The problem with refreshing dired buffers is that it may take time if the
dired is operating on remote directories (ssh, ftp ...), or have other side
effects (imagine dired making your cd-rom periodically spin when there's no
need to, even if that's probably cached by the OS anyway). Is there a
reliable way to know if accessing a file is fast and side-effects free ? If
there is, dired could hook to window-configuration change and refresh itself
whenever it's shown after being hidden or something like that.

[-- Attachment #2: Type: text/html, Size: 2117 bytes --]

Re: [Patch] Behavior of dired when there already is a dired buffer of the same directory

[Lennart Borgman (gmail)]

Antoine Levitt wrote:
> anyway). Is there a reliable way to know if accessing a file is fast and
> side-effects free ? If there is, dired could hook to


file-remote-p

Re: [Patch] Behavior of dired when there already is a dired buffer of the same directory

[Antoine Levitt]

[-- Attachment #1: Type: text/plain, Size: 628 bytes --]

That only checks for tramp/similar file handling. I don't think we can check
for the underlying file system in an OS-independent fashion (gvfs, mounts
... are all ways of making remote files look like regular files). Maybe a
solution would be to provide an option to automatically refresh, with a
regexp list of files to ignore ? (which could be set to e.g.
("^/media/cdrom", ".gvfs"))
2008/9/1 Lennart Borgman (gmail) <lennart.borgman@gmail.com>

> Antoine Levitt wrote:
> > anyway). Is there a reliable way to know if accessing a file is fast and
> > side-effects free ? If there is, dired could hook to
>
>
> file-remote-p
>

[-- Attachment #2: Type: text/html, Size: 978 bytes --]

Re: [Patch] Behavior of dired when there already is a dired buffer of the same directory

[Miles Bader]

"Antoine Levitt" <smeuuh@gmail.com> writes:
> That's a good point. However, the user is clearly offered a choice, and I
> think it would be better if this choice was made explicit by a question,
> rather than just a suggestion

It's also much more annoying for one's command flow to be interrupted by
an unexpected question prompt, and that can cause real problems in cases
where the user types commands quickly.

In general, prompting the user for optional information is a bad idea,
and this is especially true for "asynchronous" events.

-Miles

-- 
Run away!  Run away!
u

Re: [Patch] Behavior of dired when there already is a dired buffer of the same directory

[Stefan Monnier]

> It's also much more annoying for one's command flow to be interrupted by
> an unexpected question prompt, and that can cause real problems in cases
> where the user types commands quickly.

> 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.


        Stefan

Re: [Patch] Behavior of dired when there already is a dired buffer of the same directory

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>> It's also much more annoying for one's command flow to be interrupted by
>> an unexpected question prompt, and that can cause real problems in cases
>> where the user types commands quickly.
> 
>> 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.


Is not that a very different situation?

In the case of dired it is about what is displayed in Emacs. In the case
of files it is also about the content of a buffer and reverting can make
edits go away.

Re: [Patch] Behavior of dired when there already is a dired buffer of the same directory

[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.

Re: [Patch] Behavior of dired when there already is a dired buffer of the same directory

[Antoine Levitt]

[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]

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.
>

[-- Attachment #2: Type: text/html, Size: 2038 bytes --]