bug#65186: 29.0.91; `dired-free-space' is a step backward

bug#65186: 29.0.91; `dired-free-space' is a step backward

[Drew Adams]

Dunno how such a change was made to the _default_ Emacs behavior.
Shouldn't have happened, IMHO.

Two main problems with this self-styled enhancement:

1. The default behavior should be what we've always had, which
corresponds to NONE of the `dired-free-space' option values.

(It's maybe telling that the option name is about free space, whereas
the detailed info is much more than that.  Maybe that's all that
Someone(TM) thought was important.)

2. Even if you set the option to `separate', so you see the full info,
you can't get the superior previous behavior, which is that there's _no
such info_ shown when you hide details (`(').

Instead, Someone(TM) maybe thought that those interested in what
Someone(TM) doesn't think interesting - the full info - always want to
see that info, even with details hidden.  Blinders...

In GNU Emacs 29.0.91 (build 2, x86_64-w64-mingw32) of 2023-05-14 built
 on AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Pro (v10.0.2009.19045.3208)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation
 --without-compress-install --with-tree-sitter CFLAGS=-O2'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

(NATIVE_COMP present but libgccjit not available)

bug#65186: 29.0.91; `dired-free-space' is a step backward

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> Date: Wed, 9 Aug 2023 22:03:36 +0000
> 
> Dunno how such a change was made to the _default_ Emacs behavior.
> Shouldn't have happened, IMHO.
> 
> Two main problems with this self-styled enhancement:
> 
> 1. The default behavior should be what we've always had, which
> corresponds to NONE of the `dired-free-space' option values.

The 'separate' value (which is not the default) produces the behavior
we had in Emacs 28 and older, so why do you say that "what we always
had corresponds to none" of the option's values?

> 2. Even if you set the option to `separate', so you see the full info,
> you can't get the superior previous behavior, which is that there's _no
> such info_ shown when you hide details (`(').
> 
> Instead, Someone(TM) maybe thought that those interested in what
> Someone(TM) doesn't think interesting - the full info - always want to
> see that info, even with details hidden.  Blinders...

I think it was just an oversight, now fixed on the emacs-29 branch.

bug#65186: 29.0.91; `dired-free-space' is a step backward

[Drew Adams]

> > Two main problems with this self-styled enhancement:
> >
> > 1. The default behavior should be what we've always had, which
> > corresponds to NONE of the `dired-free-space' option values.
> 
> The 'separate' value (which is not the default) produces the behavior
> we had in Emacs 28 and older, so why do you say that "what we always
> had corresponds to none" of the option's values?

No, it doesn't.  Not with `emacs -Q' on MS Windows (which uses ls-lisp), at least.  Not in 28.2 or ANY earlier release, going back to when `dired-hide-details-mode' was first introduced.  In all releases, if you use `(' to hide details then that "separate" line is one of the details that's _removed_.

> > 2. Even if you set the option to `separate', so you see the full info,
> > you can't get the superior previous behavior, which is that there's _no
> > such info_ shown when you hide details (`(').
> >
> > Instead, Someone(TM) maybe thought that those interested in what
> > Someone(TM) doesn't think interesting - the full info - always want to
> > see that info, even with details hidden.  Blinders...
> 
> I think it was just an oversight, now fixed on the emacs-29 branch.

Thank you very much, Eli.
(I don't build Emacs, but I'm guessing you mean what I hope you mean. ;-))

IF all you changed was to make `separate' be the default or IF it was only to hide all such info when hiding details, then that doesn't fix what I'd like to see fixed.

I'd like to see both:

1. The default behavior as it was before: when details aren't hidden, show the full info on a separate line, and when details are hidden, don't show any such info (available, used, etc.).

2. For _each_ of the option values: when details are hidden, don't show any such info.  (Unless you add a separate option value for something different.  At least let users get the old behavior exactly, as one possibility) 

bug#65186: 29.0.91; `dired-free-space' is a step backward

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "65186@debbugs.gnu.org" <65186@debbugs.gnu.org>
> Date: Thu, 10 Aug 2023 15:42:57 +0000
> 
> > > Two main problems with this self-styled enhancement:
> > >
> > > 1. The default behavior should be what we've always had, which
> > > corresponds to NONE of the `dired-free-space' option values.
> > 
> > The 'separate' value (which is not the default) produces the behavior
> > we had in Emacs 28 and older, so why do you say that "what we always
> > had corresponds to none" of the option's values?
> 
> No, it doesn't.  Not with `emacs -Q' on MS Windows (which uses ls-lisp), at least.  Not in 28.2 or ANY earlier release, going back to when `dired-hide-details-mode' was first introduced.  In all releases, if you use `(' to hide details then that "separate" line is one of the details that's _removed_.

If this is about hiding the disk space information, then it's your
item 2, and is now fixed.  With that taken care of, the 'separate'
value produces the disk space display identical to what Emacs 28 and
older did.

> > > 2. Even if you set the option to `separate', so you see the full info,
> > > you can't get the superior previous behavior, which is that there's _no
> > > such info_ shown when you hide details (`(').
> > >
> > > Instead, Someone(TM) maybe thought that those interested in what
> > > Someone(TM) doesn't think interesting - the full info - always want to
> > > see that info, even with details hidden.  Blinders...
> > 
> > I think it was just an oversight, now fixed on the emacs-29 branch.
> 
> Thank you very much, Eli.
> (I don't build Emacs, but I'm guessing you mean what I hope you mean. ;-))

The change I installed makes '(' hide the disk space information when
it is displayed on a separate line, under dired-free-space = 'separate'.  
This is for consistency with previous behavior of Dired.

> IF all you changed was to make `separate' be the default or IF it was only to hide all such info when hiding details, then that doesn't fix what I'd like to see fixed.

'separate' will not become default.  Emacs 29 was already released
with a different default, so that ship has sailed.  We will only
revert back to 'separate' if there will be user outcry to that effect.

> 1. The default behavior as it was before: when details aren't hidden, show the full info on a separate line, and when details are hidden, don't show any such info (available, used, etc.).
> 
> 2. For _each_ of the option values: when details are hidden, don't show any such info.  (Unless you add a separate option value for something different.  At least let users get the old behavior exactly, as one possibility) 

The default display of the disk space info is on the same line as the
directory name.  It doesn't get hidden when you press '(', and I'm not
sure it should.  I made it be hidden for the 'separate' display,
because that's how it behaved before Emacs 29, but there's no such
precedent for the default value of 'first', and so what you want to
happen in that case is just your personal opinion.  We don't need to
agree about that.

And with that, I'm closing this bug.

bug#65186: 29.0.91; `dired-free-space' is a step backward

[Drew Adams]

> > 2. For _each_ of the option values: when details are hidden, don't show
> any such info.  (Unless you add a separate option value for something
> different.  At least let users get the old behavior exactly, as one
> possibility)
> 
> The default display of the disk space info is on the same line as the
> directory name.  It doesn't get hidden when you press '(', and I'm not
> sure it should.  I made it be hidden for the 'separate' display,
> because that's how it behaved before Emacs 29, but there's no such
> precedent for the default value of 'first', and so what you want to
> happen in that case is just your personal opinion.  We don't need to
> agree about that.
> 
> And with that, I'm closing this bug.

Thanks for fixing what you fixed.

Wrt that last point/question:

1. I don't see that this is fixed even for `separate'.
I'm using Emacs 29.1.2.  I guess it was probably
fixed after that release.

2. The doc for `separate' (in 29.1.2, at least) is
incorrect, assuming this was fixed to not show the
info at all when details are hidden.

This should at least be spelled out in the doc string,
especially as someone wishing to minimize the display
might prefer `separate' but the doc for it gives the
impression that it always displays more, rather than
that it displays less when details are hidden.

3. FWIW, a reason to not want this info shown at all
when details are hidden is the case where you have
a feature that automatically sizes the window (or
frame) to the buffer-text width.

For many Dired listings file names are sufficiently
short that the buffer width would fit the longest
file name, but if the size info is shown then that
line will be the longest, and horizontal screen real
estate will be wasted, just for that line.  (And even
more space is wasted for `first' than for `separate'.)

I don't really see why users who choose `first' (the
default) would always want to see this info either.
They, even more than the `separate'ists, would want
a more minimal display, I think.

The reason you gave for not fixing this for `first'
was, I think, just that that's not the behavior in
the first release of this feature.  But neither was
the (now fixed, I hope) behavior of including the
info when `separate'.

IOW, the bug could usefully be fixed for both
`first' and `separate'.  When hiding details, what
sense does it make to increase the window width to
show such info?  Anyone who ever wants to see it
can simply hit `('.  And perhaps `(' again, to hide
details again.

Please reconsider your decision not to fix this
for all choices of `dired-free-space' when details
are hidden.  Hiding details should hide details.

The doc for that option might also usefully say
that if you change the value interactively, then
to see the effect in any existing Dired buffer
you can use `C-x v RET' (or similar).  IOW, let
users know not to expect that simply changing the
value changes an existing Dired buffer's display.

Thanks in advance for thinking this over again.