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

["Antoine Levitt" <smeuuh@gmail.com>]

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