all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: "65186-done@debbugs.gnu.org" <65186-done@debbugs.gnu.org>
Subject: bug#65186: 29.0.91; `dired-free-space' is a step backward
Date: Thu, 9 Nov 2023 17:42:36 +0000	[thread overview]
Message-ID: <SJ0PR10MB5488DFEF8F3A807E26FE1827F3AFA@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <835y5miyhw.fsf@gnu.org>

> > 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.





      reply	other threads:[~2023-11-09 17:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-09 22:03 bug#65186: 29.0.91; `dired-free-space' is a step backward Drew Adams
2023-08-10  6:12 ` Eli Zaretskii
2023-08-10 15:42   ` Drew Adams
2023-08-10 17:43     ` Eli Zaretskii
2023-11-09 17:42       ` Drew Adams [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SJ0PR10MB5488DFEF8F3A807E26FE1827F3AFA@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=65186-done@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.