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

[Drew Adams]

>     It seems to work on a short test; however, I do like the long listing
>     that dired provides, I especially find it important to see permission,
>     owners, size, and date, as well name.  And I hardly ever use frames.
>
> What does dired-details.el have to do with frames?

This was already explained in the thread, but I will repeat it, since you
ask.

If you use a one-buffer frame for each Dired buffer, and you shrink the
buffer horizontally by hiding all info but the file names, then it makes
sense to also shrink the frame. Otherwise, you've gained nothing in terms of
display real estate. That is the motivation for automatically fitting the
frame. Similarly, if you expand the displayed buffer contents, then it makes
sense to expand the frame to fit it, so lines don't wrap. The idea is to
synchronize the frame display with the buffer display.

I was clear from the beginning, however, that I was _not_ proposing that the
frame-fitting in dired-details+ be included in Emacs:

July 2:
> The frame-fitting enhancement need not be applied, since Emacs
> does not yet have my frame-fitting code. But I think some of
> the other enhancements could be integrated.

July 4:
> No, not really. As I said, the frame-fitting part is optional...
> I use non-nil pop-up-frames, so frame fitting is important to me,
> but it is not necessary for the other features provided by
> dired-details+.el. You can no doubt imagine that without frame
> fitting not much would be gained by removing Dired details: the
> frame would occupy just as much screen real estate as for
> the detailed listing.

There was also a discussion of possibly fitting the Emacs window as well,
for those who do not use one buffer per frame. There is currently no code
written to do that, but, IMO, it would be a useful addition. Here is that
exchange:

> > similar to how your frames shrink, Dired could split the window
> > and show more when you got space back from hiding details...
>
> I agree that it could be good to automatically expand and contract
> the current Dired window or windows (just as I do with the frame),
> provided that a user agrees with that behavior via an option
> (somewhere). I have not implemented that - patches welcome ;-).

For the record -

1. The frame-fitting call in dired-details+.el has no effect if either (a)
user option `autofit-frames-flag' is nil or (b) there is more than one
window in the frame. Here is the function called in dired-details+.el, _if_
it is available (soft require, fboundp):

(defun fit-frame-if-one-window ()
  "Resize frame to fit selected window if it is alone in the frame.
Usable in `temp-buffer-show-hook'.
This does nothing if `autofit-frames-flag' is nil."
  (and (one-window-p t) autofit-frames-flag (fit-frame)))

2. Again, I did _not_, in any case, propose that the dired-details+.el call
to `fit-frame-if-one-window' be installed in Emacs, "since Emacs does not
yet have my frame-fitting code."

FYI - Besides the modal display preference (new Dired buffers use the
current display state), which you have rejected, dired-details+ just makes
dired-details update the display automatically:

1. By refreshing the current hide/show state whenever the listing of files
changes (e.g. new file). Think of this as a kind of refresh or revert.

2. By fitting the frame when the hide/show state changes.

I propose adding #1 now. If frame-fitting code is later added to Emacs, then
#2 might also be considered at that time.