GNU bug report logs - #20943
25.0.50; Dired buffers are not always auto-reverterd

Previous Next

Full log

Message #83 received at 20943 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Michael Albinus <michael.albinus <at> gmx.de>, Mark Karpov
 <markkarpov <at> openmailbox.org>
Cc: 20943 <at> debbugs.gnu.org
Subject: RE: bug#20943: 25.0.50; Dired buffers are not always auto-reverterd
Date: Sat, 4 Jul 2015 07:33:24 -0700 (PDT)

> This is a feature of dired. It doesn't want to regenerate the whole
> dired buffer; instead it adds the new entry at the position the
> cursor is pointing to. This is because reverting the dired buffer
> could be expensive. Think about a remote directory, think about many
> inserted subdirectories.

Dunno whether performance was the only reason for doing this, but
another benefit I see to the current behavior is that, because the
change is shown next to point, *you see it*, even if `g' reordering
might place it far way or even off-screen.  It is important that
users have feedback about changs.  And when the changed/new file
is somehow derived from the file at point (e.g., it is a copy),
seeing the two right next to each other means you can immediately
compare the names etc. 

This keep-it-right-here-for-now behavior is quite important, (to me
at least). When I copy a file to the same directory, for instance,
and give the copy a name with a prefix (e.g. 2015-07-04) that might
make it sort far away, I can nevertheless see it right there.

This is about the same reason that we highlight new files (e.g.,
copies) specially, so you notice them easily.

This gives users control over when to re-sort (using, e.g., `g').
We should not assume that re-sorting automatically is what a user
wants.

If we were to change this, I would very much like the changed
behavior to be only an option, and not the default behavior.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.