* bug#65186: 29.0.91; `dired-free-space' is a step backward @ 2023-08-09 22:03 Drew Adams 2023-08-10 6:12 ` Eli Zaretskii 0 siblings, 1 reply; 5+ messages in thread From: Drew Adams @ 2023-08-09 22:03 UTC (permalink / raw) To: 65186 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) ^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#65186: 29.0.91; `dired-free-space' is a step backward 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 0 siblings, 1 reply; 5+ messages in thread From: Eli Zaretskii @ 2023-08-10 6:12 UTC (permalink / raw) To: Drew Adams; +Cc: 65186 > 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#65186: 29.0.91; `dired-free-space' is a step backward 2023-08-10 6:12 ` Eli Zaretskii @ 2023-08-10 15:42 ` Drew Adams 2023-08-10 17:43 ` Eli Zaretskii 0 siblings, 1 reply; 5+ messages in thread From: Drew Adams @ 2023-08-10 15:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 65186@debbugs.gnu.org > > 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) ^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#65186: 29.0.91; `dired-free-space' is a step backward 2023-08-10 15:42 ` Drew Adams @ 2023-08-10 17:43 ` Eli Zaretskii 2023-11-09 17:42 ` Drew Adams 0 siblings, 1 reply; 5+ messages in thread From: Eli Zaretskii @ 2023-08-10 17:43 UTC (permalink / raw) To: Drew Adams; +Cc: 65186-done > 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#65186: 29.0.91; `dired-free-space' is a step backward 2023-08-10 17:43 ` Eli Zaretskii @ 2023-11-09 17:42 ` Drew Adams 0 siblings, 0 replies; 5+ messages in thread From: Drew Adams @ 2023-11-09 17:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 65186-done@debbugs.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. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-11-09 17:42 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).