[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Patch] Behavior of dired when there already is a dired buffer of th

From: Antoine Levitt
Subject: Re: [Patch] Behavior of dired when there already is a dired buffer of the same directory
Date: Mon, 1 Sep 2008 02:53:06 +0200

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


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]