RE: dired-details: show/hide file details in Dired

[Drew Adams]

>     How about also installing the enhancements provided by
>     dired-details+.el?
>
> Once dired-details.el is installed, please post a copy
> and we can think about which of its features we want to install.

I already posted a copy, here:
http://www.emacswiki.org/cgi-bin/wiki/dired-details%2b.el.

>     1. Update the hide/show overlays automatically whenever you
>        create new files or directories or rename existing files
>        or directories. This means tweaking the definitions of
>        `dired-byte-compile', `dired-compress',
>        `dired-create-files' and `dired-create-directory' (instead
>        of advising them).
>
> That sounds useful.  What precisely are the "hide/show overlays", though?
> Which feature uses them?  Is that something in dired-details?

Yes. dired-details uses "an invisible, evaporable overlay for each
file-line's details", to quote the doc string of `dired-details-hide'.

AFAICT, this dired-details+ feature corresponds to the only TODO item in
dired-details: "add a hook for dired-add-file to hide new entries as
necessary". Without this feature, any of the changes mentioned (e.g. adding
a file) results in a full, detailed display of the target file, instead of
keeping its display in sync with the rest of the Dired buffer (details
hidden or shown).

The dired-details+ code (like the dired-details code) uses defadvice. If
this display-sync feature is added to Emacs, then the following code or
equivalent would need to be added at the end of each of the functions
mentioned, to be able to get rid of the defadvice that implements this
feature:

 (dired-details-delete-overlays)
 (dired-details-activate)

Suitably guarded by `fboundp' or `featurep', perhaps, so that it is used
only with dired-details. All this code does is update the buffer display, to
synchronize it for the target files.

>     2. Provide a user option, `dired-details-propagate-flag'
>        which, if non-nil, propagates the last hide/show state
>        you chose to the next Dired buffer you open.
>
> I would rather not install that.

In that case, then that should be the only behavior, IMO, not what is
defined in dired-details.el. That is, if you don't want to have a user
option for this, then IMO the behavior should be to let the hide/show
toggling affect future Dired buffers, instead of them all defaulting to the
same initial state. The toggle is still local, so display of existing Dired
buffers is not affected, but if you open Dired on other directories (e.g.
subdirs or parent dirs), then the current display state (hidden or shown) is
used (instead of some default state).

In my use, at least, this makes more sense, because it requires a lot less
toggling. Typically, if I currently want to hide (show) details in some
Dired buffer, then I probably want to do the same in the next Dired buffer I
open. It is not the case that I always want to start every Dired buffer in
the same default state. Without this modal behavior, you need to toggle more
often or you need to periodically re-customize the default state. The user's
current display state is a better guide to how s?he wants the next Dired
buffer to be displayed than is some default value.

I also recommend that the empty string (instead of "[...]") be used as the
default value of the hidden string (used for the overlay). For one thing, it
saves screen real estate. For another thing, it makes window and frame
fitting easier and more accurate. For another thing, someone who uses
dired-details will not need a "[...]" reminder that there is hidden text
present - that's pretty useless, IMO. If you are keen on not multiplying
user options, then I'd say just hard-code this as the empty string.

That sums up the tweaks that dired-details+ makes to dired-details. There
are only a few dozen lines of code in the file.