bug#14940: 24.3.50; [PATCH] enhancement for `dired-hide-details-mode'

[Drew Adams <drew.adams@oracle.com>]

> > 1. Users can decide whether the initial hide/show state of new Dired
> >    buffers reflects the last chosen state for a Dired buffer.  This is
> >    decided by option `dired-hide-details-propagate'.  Non-nil means
> >    propagate the last chosen state as the initial state of a new Dired
> >    buffer.
> 
> > 2. If `dired-hide-details-propagate' is nil, or if the user has not
> >    yet explicitly changed any Dired hide/show state, then option
> >    `dired-hide-details-initially' defines the initial state of a new
> >    Dired buffer.  IOW, it specifies what the "last" state defaults to.
> 
> Hmm... couldn't we merge those two configuration variables?

I supppose you mean shouldn't, not couldn't.

> Here's the idea:
> - Rename dired-hide-details-initially to dired-hide-details-default-mode,
>   a new (global) minor mode which determines how new dired buffers show up.
> - Make it so that toggling dired-hide-details-default-mode also toggles the
>   dired-hide-details-mode in the current buffer.
> This way, instead of setting dired-hide-details-propagate to t, users
> can simply use dired-hide-details-default-mode instead of
> dired-hide-details-mode.

I see no advantage, only disadvantage.  User options are generally the place
for default user settings.  Why have two minor modes here?  I might be
missing something, but to my mind that only confuses users and offers no
advantage.

We should stick to a single command and its key binding, and not make users
jump through hoops (yes, including changing key bindings) to choose the default
behavior they want (wrt initial hide/show and wrt propagation).

And if the same key and command are used (not two different mode commands),
a user can easily toggle the option value at any time and have the behavior
change - no fiddling with different commands or rebinding keys.

But if the *same* behavior is offered by your proposal as by mine, and if
users are not additionally bothered by your proposal, then I guess I
don't see a problem with it.  (That's an if.)

IMO:

1. The out-of-the-box default behavior should be as I described.

2. Users should be able to set their own preferred default behavior
persistently.  To me, that means a user option.  In any case, it
means not having to toggle anything interactively just to get the
preferred behavior as the saved one.

3. If the rest of the behavior I described is also provided, no problem.

In sum, it's the behavior I'm interested in.  If the behavior is intact
then I don't care much how you decide to implement it.

The code I sent is in Dired+ at least, so it is anyway available to users
who choose it, should you decide it is not the behavior you want for
vanilla Emacs.  Obviously I would prefer that (a) everyone benefit from
this feature and (b) I can then remove it from Dired+.  If you implement
something different then I will see whether I like its behavior enough
to remove what I have now in Dired+.

If you think I am missing something, please fill me in.

> Your code often exceeds the 80 columns limit.

Often?  Four of the 113 lines are longer than 80 chars (83, 84, 84, 85).

The longest line in dired.el is 103 chars!, both before and after patch.
The longest line in the patch I sent is 85 chars.  But feel free to
shorten any lines you like.