bug#44273: "total used in directory 19 available 5.2 GiB"

bug#44273: "total used in directory 19 available 5.2 GiB"

[積丹尼 Dan Jacobson]

$ emacs .
  /home/norfelsburg:
  total used in directory 19 available 5.2 GiB

What does that mean, 19 GiB?

Therefore let's get rolling with Proper English!

Step one, proper capitalization:
  Total used in directory 19 available 5.2 GiB

OK, now let's get to work on that 19:
Maybe it means "blocks". OK, let's say so:
  Total used in directory 19 blocks available 5.2 GiB

OK, now how about a comma:
  Total used in directory 19 blocks, available 5.2 GiB

And for a grand slam, a period at the back!:
  Total used in directory 19 blocks, available 5.2 GiB.

Sure, ls still says the mysterious
$ ls -l
total 19

But you emacs guys made a more readable version, but still not clear
enough.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Mattias Engdegård]

>  total used in directory 19 available 5.2 GiB What does that mean, 19 GiB? 

Dan, you are absolutely right. It's terrible but it cannot be fixed and the useless number (19) cannot even be removed. Sorry.

See bug 36729.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Lars Ingebrigtsen]

Mattias Engdegård <mattiase@acm.org> writes:

>>  total used in directory 19 available 5.2 GiB What does that mean, 19 GiB? 
>
> Dan, you are absolutely right. It's terrible but it cannot be fixed
> and the useless number (19) cannot even be removed. Sorry.

Indeed.  Well, it can be made more comprehensible:

total used in directory: 19 units; free space on disk: 5.2 GiB

(with a help tooltips on the units).

But I really don't know why dired displays this stuff at all.  It seems
irrelevant: The "total" is incomprehensible in any case, and the free
space stuff isn't something I've asked for: If I want to know, it's just
a standard command away.

So I think the line should just be removed; perhaps with a defcustom
(defaulting to off).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44273: "total used in directory 19 available 5.2 GiB"

[Mattias Engdegård]

28 okt. 2020 kl. 11.43 skrev Lars Ingebrigtsen <larsi@gnus.org>:

> But I really don't know why dired displays this stuff at all.  It seems
> irrelevant: The "total" is incomprehensible in any case, and the free
> space stuff isn't something I've asked for: If I want to know, it's just
> a standard command away.
> 
> So I think the line should just be removed; perhaps with a defcustom
> (defaulting to off).

I'm all for removing it, but there is the usual howling crowd insisting that it is indispensable and highly meaningful on their machine and how dare we even think of changing anything in Emacs. Good luck.
That's why bug#36729 was closed as wontfix. (This is a duplicate.)

bug#44273: "total used in directory 19 available 5.2 GiB"

[Lars Ingebrigtsen]

Mattias Engdegård <mattiase@acm.org> writes:

> I'm all for removing it, but there is the usual howling crowd
> insisting that it is indispensable and highly meaningful on their
> machine and how dare we even think of changing anything in Emacs. Good
> luck.

:-)  That's quite common, yes, and sometimes it's justified, even.

> That's why bug#36729 was closed as wontfix. (This is a duplicate.)

I didn't see any howling in that bug report, though?  I just skimmed it
quickly.

As an aside: The general design of dired is frustrating.  Dumping
whatever the system "ls" gives us into a buffer and then trying to make
do isn't a good approach.

The argument that Tramp needs to parse "ls" output is valid, and that
"ls" is faster than `ls-lisp' is, too, but it's still backwards: Dired
should take a well-defined data structure and then render it according
to however the user wants.

The data can come from `ls-lisp', but it could also come from "ls": We
just need to write a parser that parses the data.  That's infinitely
more viable than the gazillion tweaks we've added to dired to do the
right thing if "-F" adds "@" at the end or not, etc etc etc.  All the
nasty parsing stuff would be contained to a single parsing function and
not infest all of dired.

Anyway.  Implementing this is left as a weekend project for somebody.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44273: "total used in directory 19 available 5.2 GiB"

[Mattias Engdegård]

forcemerge 44273 36379
stop

28 okt. 2020 kl. 12.02 skrev Lars Ingebrigtsen <larsi@gnus.org>:

> I didn't see any howling in that bug report, though?  I just skimmed it
> quickly.

I think there was some discussion (if you can call it that) outside that report, but I may be misremembering.

> As an aside: The general design of dired is frustrating.  Dumping
> whatever the system "ls" gives us into a buffer and then trying to make
> do isn't a good approach.
> 
> The argument that Tramp needs to parse "ls" output is valid, and that
> "ls" is faster than `ls-lisp' is, too, but it's still backwards: Dired
> should take a well-defined data structure and then render it according
> to however the user wants.

Definitely, and if it is faster to fork another process and parse its output with slow regexps in Emacs to do the job of what ordinarily just takes a few syscalls, then we aren't doing our job properly. It's not hard to read directories efficiently.

In any case I'm merging the bugs, optimistically keeping them open.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Lars Ingebrigtsen]

Mattias Engdegård <mattiase@acm.org> writes:

> Definitely, and if it is faster to fork another process and parse its
> output with slow regexps in Emacs to do the job of what ordinarily
> just takes a few syscalls, then we aren't doing our job properly. It's
> not hard to read directories efficiently.

True.  If `ls-lisp' (or something similar) isn't fast enough, then it
should be pretty easy to add a C-level function for efficient directory
reading.  (But we'd still need the parser for Tramp.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44273: "total used in directory 19 available 5.2 GiB"

[Andreas Schwab]

On Okt 28 2020, Lars Ingebrigtsen wrote:

> True.  If `ls-lisp' (or something similar) isn't fast enough, then it
> should be pretty easy to add a C-level function for efficient directory
> reading.

That would require re-implementing each and every ls implementation, to
handle all possible command line arguments.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#44273: "total used in directory 19 available 5.2 GiB"

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> That would require re-implementing each and every ls implementation, to
> handle all possible command line arguments.

Of course not.  The directory data is delivered to new-dired in some
well-defined format, and it's then displayed as the user wants.  ls
switches aren't involved.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44273: "total used in directory 19 available 5.2 GiB"

[Mattias Engdegård]

28 okt. 2020 kl. 13.10 skrev Lars Ingebrigtsen <larsi@gnus.org>:

> Andreas Schwab <schwab@linux-m68k.org> writes:
> 
>> That would require re-implementing each and every ls implementation, to
>> handle all possible command line arguments.
> 
> Of course not.  The directory data is delivered to new-dired in some
> well-defined format, and it's then displayed as the user wants.  ls
> switches aren't involved.

Perhaps what Andreas meant is what since Dired is defined in terms of the behaviour of the 'ls' command it runs, and users can specify arbitrary command-line switches, we cannot really change much of it.

More likely we should consider Dired a lost cause that cannot be fixed because of its design, and write a modern alternative.
That would have many benefits, including not being tied to a particular output format just for the sake of tradition.
Presumably that is what you meant by new-dired?

bug#44273: "total used in directory 19 available 5.2 GiB"

[Andreas Schwab]

The strength of Dired is that it presents the directory in a well-known
format, and you can control its layout in a familiar way.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#44273: "total used in directory 19 available 5.2 GiB"

[Lars Ingebrigtsen]

Mattias Engdegård <mattiase@acm.org> writes:

> Perhaps what Andreas meant is what since Dired is defined in terms of
> the behaviour of the 'ls' command it runs, and users can specify
> arbitrary command-line switches, we cannot really change much of it.

Sure we can, as long as there's an upgrade path.  We deprecate, say,
dired-ls-sorting-switches but introduce a new, Lisp-ey variable that
does the same (and provides reasonable defaults by looking at and
interpreting the obsolete variable).

> More likely we should consider Dired a lost cause that cannot be fixed
> because of its design, and write a modern alternative.
> That would have many benefits, including not being tied to a
> particular output format just for the sake of tradition.
> Presumably that is what you meant by new-dired?

No -- there are several alternative file browsers in Emacs.  What
matters is the default one, because that's the one with an approximately
infinite number of open bug reports that can't realistically be fixed,
and that's dired.

I think it's feasible to rewrite dired to be sane without breaking too
much stuff -- not a 100% drop in replacement, but close enough that most
people won't notice (except that it would have fewer bugs).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44273: "total used in directory 19 available 5.2 GiB"

[Drew Adams]

> forcemerge 44273 36379

Did you perhaps really mean to merge 36729, not 36379?

bug#44273: "total used in directory 19 available 5.2 GiB"

[Mattias Engdegård]

28 okt. 2020 kl. 15.39 skrev Drew Adams <drew.adams@oracle.com>:

>> forcemerge 44273 36379
> 
> Did you perhaps really mean to merge 36729, not 36379?

Yes, it was a mistake (since corrected). Thanks for pointing it out all the same.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 28 Oct 2020 11:43:19 +0100
> Cc: 積丹尼 Dan Jacobson <jidanni@jidanni.org>,
>  44273@debbugs.gnu.org
> 
> total used in directory: 19 units; free space on disk: 5.2 GiB
> 
> (with a help tooltips on the units).
> 
> But I really don't know why dired displays this stuff at all.  It seems
> irrelevant: The "total" is incomprehensible in any case, and the free
> space stuff isn't something I've asked for: If I want to know, it's just
> a standard command away.
> 
> So I think the line should just be removed; perhaps with a defcustom
> (defaulting to off).

Why don't you ask the Coreutils developers to remove that from 'ls'
display as well, then?

bug#44273: "total used in directory 19 available 5.2 GiB"

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 28 Oct 2020 12:02:06 +0100
> Cc: 積丹尼 Dan Jacobson <jidanni@jidanni.org>,
>  44273@debbugs.gnu.org
> 
> The argument that Tramp needs to parse "ls" output is valid, and that
> "ls" is faster than `ls-lisp' is, too, but it's still backwards: Dired
> should take a well-defined data structure and then render it according
> to however the user wants.

I think it would be useful to measure the difference in speed between
ls-lisp and 'ls' the program on various platforms.  For example, use
benchmark-run to time (dired "foo") with some large directory 'foo',
with and without ls-lisp loaded.  (This should be done with a warm
disk cache.)  This should tell us how badly we need to speed up
ls-lisp.

Profiling ls-lisp could also be educational.  For example, I see in
the profile on my system that this loop:

	(let ((locale system-time-locale))
	  (if (not locale)
	      (let ((vars '("LC_ALL" "LC_TIME" "LANG")))
		(while (and vars (not (setq locale (getenv (car vars)))))
		  (setq vars (cdr vars)))))

is run for each file, which is definitely a waste of cycles.  My
measurements indicate that running this loop just once could speed up
ls-lisp by 25%.

> The data can come from `ls-lisp', but it could also come from "ls": We
> just need to write a parser that parses the data.

The data which comes from 'ls' can take many different formats,
depending on the switches.  Parsing each and every one of them sounds
daunting.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 28 Oct 2020 12:23:22 +0100
> Cc: 積丹尼 Dan Jacobson <jidanni@jidanni.org>,
>  44273@debbugs.gnu.org
> 
> Mattias Engdegård <mattiase@acm.org> writes:
> 
> > Definitely, and if it is faster to fork another process and parse its
> > output with slow regexps in Emacs to do the job of what ordinarily
> > just takes a few syscalls, then we aren't doing our job properly. It's
> > not hard to read directories efficiently.
> 
> True.  If `ls-lisp' (or something similar) isn't fast enough, then it
> should be pretty easy to add a C-level function for efficient directory
> reading.

Are you sure it's reading the directory that takes the lion's share of
the time?  Maybe it's inserting the file information, one file at a
time, into a buffer?  Or something else?

That's why I suggested to profile and benchmark this thing.

>  (But we'd still need the parser for Tramp.)

Tramp could always use what it does now, or use ls-lisp, or something
else.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Wed, 28 Oct 2020 12:47:09 +0100
> Cc: Mattias Engdegård <mattiase@acm.org>,
>  積丹尼 Dan Jacobson <jidanni@jidanni.org>,
>  44273@debbugs.gnu.org
> 
> On Okt 28 2020, Lars Ingebrigtsen wrote:
> 
> > True.  If `ls-lisp' (or something similar) isn't fast enough, then it
> > should be pretty easy to add a C-level function for efficient directory
> > reading.
> 
> That would require re-implementing each and every ls implementation, to
> handle all possible command line arguments.

Wouldn't it be enough to implement only what GNU 'ls' does?  If some
users will be unhappy with that and will want something their native
'ls' does, they can always go back to the old behavior (which we will
need to leave in any case for backward compatibility).

bug#44273: "total used in directory 19 available 5.2 GiB"

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Why don't you ask the Coreutils developers to remove that from 'ls'
> display as well, then?

I believe this line is mandated by POSIX.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 28 Oct 2020 08:55:52 -0700
> Cc: mattiase@acm.org, jidanni@jidanni.org, 44273@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why don't you ask the Coreutils developers to remove that from 'ls'
> > display as well, then?
> 
> I believe this line is mandated by POSIX.

Does POSIX mandate what 'ls' outputs when invoked with the --dired
switch?

bug#44273: "total used in directory 19 available 5.2 GiB"

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Why don't you ask the Coreutils developers to remove that from 'ls'
>> > display as well, then?
>>
>> I believe this line is mandated by POSIX.
>
> Does POSIX mandate what 'ls' outputs when invoked with the --dired
> switch?

Sorry, I didn't realize you were referring to that flag.  (But maybe I
should have...)

I don't think POSIX says anything about the --dired flag.  It's a GNU
extension.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 28 Oct 2020 17:03:56 -0700
> Cc: larsi@gnus.org, mattiase@acm.org, jidanni@jidanni.org, 
> 	44273@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > Why don't you ask the Coreutils developers to remove that from 'ls'
> >> > display as well, then?
> >>
> >> I believe this line is mandated by POSIX.
> >
> > Does POSIX mandate what 'ls' outputs when invoked with the --dired
> > switch?
> 
> Sorry, I didn't realize you were referring to that flag.  (But maybe I
> should have...)
> 
> I don't think POSIX says anything about the --dired flag.  It's a GNU
> extension.

So then GNU 'ls' could do anything Emacs needs when 'ls' is invoked
with --dired, including removing that line.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > But I really don't know why dired displays this stuff at all.

Because some people find it useful.

If we want that line to look different, it would be easy
for Dired to edit it after reading it from ls.  But we
should not delete the  data in it.

If you don't want that line, you could customize your Dired to delete
it.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#44273: "total used in directory 19 available 5.2 GiB"

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> True.  If `ls-lisp' (or something similar) isn't fast enough, then it
>> should be pretty easy to add a C-level function for efficient directory
>> reading.
>
> Are you sure it's reading the directory that takes the lion's share of
> the time?  Maybe it's inserting the file information, one file at a
> time, into a buffer?  Or something else?
>
> That's why I suggested to profile and benchmark this thing.
>
>>  (But we'd still need the parser for Tramp.)
>
> Tramp could always use what it does now, or use ls-lisp, or something
> else.

Counting in the sources, there are already 4 different implementations
of insert-directory in Tramp. One of it uses ls-lisp, another uses a
remote "ls" call.

If there shall be a reimplementation, I would even consider to add
another implementation, based on Perl or Python. This shall minimize
performance penalties.

Best regards, Michael.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Andreas Schwab]

On Okt 29 2020, Eli Zaretskii wrote:

> So then GNU 'ls' could do anything Emacs needs when 'ls' is invoked
> with --dired, including removing that line.

The --dired flag is not supposed to change the format, only to make it
machine readable.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#44273: "total used in directory 19 available 5.2 GiB"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > So then GNU 'ls' could do anything Emacs needs when 'ls' is invoked
  > with --dired, including removing that line.

It could, but there is no reason to do that.  Please don't make that
change, either in ls, or in Dired mode itself.

It is easy for a user to make a dired-mode-hook function delete that
line if it is present.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#44273: "total used in directory 19 available 5.2 GiB"

[Juri Linkov]

> It is easy for a user to make a dired-mode-hook function delete that
> line if it is present.

Maybe it could help to show some explanation with tooltips
over cryptic parts of that line.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  mattiase@acm.org,  larsi@gnus.org,
>   jidanni@jidanni.org,  stefankangas@gmail.com,  44273@debbugs.gnu.org
> Date: Fri, 30 Oct 2020 09:18:42 +0200
> 
> > It is easy for a user to make a dired-mode-hook function delete that
> > line if it is present.
> 
> Maybe it could help to show some explanation with tooltips
> over cryptic parts of that line.

Given that the units seem to be in general unknowable, what would you
suggest to say in that tooltip?

bug#44273: "total used in directory 19 available 5.2 GiB"

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Given that the units seem to be in general unknowable, what would you
> suggest to say in that tooltip?

That's it's unknowable (or rather -- read the ls man page).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44273: "total used in directory 19 available 5.2 GiB"

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> So I think the line should just be removed; perhaps with a defcustom
>> (defaulting to off).
>
> Why don't you ask the Coreutils developers to remove that from 'ls'
> display as well, then?

I don't see why.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44273: "total used in directory 19 available 5.2 GiB"

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> The data can come from `ls-lisp', but it could also come from "ls": We
>> just need to write a parser that parses the data.
>
> The data which comes from 'ls' can take many different formats,
> depending on the switches.  Parsing each and every one of them sounds
> daunting.

But dired does parse the output.  It's just that it leaves all the
artefacts in the buffer, leading all the commands to have workarounds
for different layouts. 

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44273: "total used in directory 19 available 5.2 GiB"

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Juri Linkov <juri@linkov.net>,  rms@gnu.org,  mattiase@acm.org,
>   jidanni@jidanni.org,  stefankangas@gmail.com,  44273@debbugs.gnu.org
> Date: Fri, 30 Oct 2020 12:33:58 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Given that the units seem to be in general unknowable, what would you
> > suggest to say in that tooltip?
> 
> That's it's unknowable (or rather -- read the ls man page).

Is that really a useful tooltip?

bug#44273: "total used in directory 19 available 5.2 GiB"

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: mattiase@acm.org,  jidanni@jidanni.org,  44273@debbugs.gnu.org
> Date: Fri, 30 Oct 2020 12:36:07 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> The data can come from `ls-lisp', but it could also come from "ls": We
> >> just need to write a parser that parses the data.
> >
> > The data which comes from 'ls' can take many different formats,
> > depending on the switches.  Parsing each and every one of them sounds
> > daunting.
> 
> But dired does parse the output.

And frequently fails, without the support provided by --dired.

And its parsing is only partial anyway.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> That's it's unknowable (or rather -- read the ls man page).
>
> Is that really a useful tooltip?

Yes.

But, like I said, it'd be better to remove the line.  It takes up
valuable screen space for little use.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44273: "total used in directory 19 available 5.2 GiB"

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: juri@linkov.net,  rms@gnu.org,  mattiase@acm.org,  jidanni@jidanni.org,
>   stefankangas@gmail.com,  44273@debbugs.gnu.org
> Date: Fri, 30 Oct 2020 12:41:29 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> That's it's unknowable (or rather -- read the ls man page).
> >
> > Is that really a useful tooltip?
> 
> Yes.
> 
> But, like I said, it'd be better to remove the line.  It takes up
> valuable screen space for little use.

Then I'm sorry, but I don't understand the logic here.  'ls' shows
this "useless" information, and yet you don't think it should be
removed from 'ls', and all the users of 'ls' evidently don't mind
seeing it.  But in Emacs the same information is somehow not useful
enough to be shown?  That doesn't add up.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> Because some people find it useful.

Do you have data to back that up?  :-)

> If we want that line to look different, it would be easy
> for Dired to edit it after reading it from ls.  But we
> should not delete the  data in it.
>
> If you don't want that line, you could customize your Dired to delete
> it.

My suggestion is to not display the line by default.  People who do find
it useful can switch it on (but I doubt they exist in large numbers).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44273: "total used in directory 19 available 5.2 GiB"

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 30 Oct 2020 13:22:24 +0100
> Cc: Dan Jacobson <jidanni@jidanni.org>, 44273@debbugs.gnu.org
> 
> My suggestion is to not display the line by default.  People who do find
> it useful can switch it on (but I doubt they exist in large numbers).

An alternative would be to replace this line with a similar one, but
in which the units are under our control, and can be spelled out.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> My suggestion is to not display the line by default.  People who do find
>> it useful can switch it on (but I doubt they exist in large numbers).
>
> An alternative would be to replace this line with a similar one, but
> in which the units are under our control, and can be spelled out.

This could decrease performance, because you need to calculate the size
of all files there. Think about a directory with several thousand
files, located remotely. And we don't have "du" for all Tramp backends.

Best regards, Michael.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  jidanni@jidanni.org,  rms@gnu.org,
>   44273@debbugs.gnu.org
> Date: Fri, 30 Oct 2020 14:39:26 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> My suggestion is to not display the line by default.  People who do find
> >> it useful can switch it on (but I doubt they exist in large numbers).
> >
> > An alternative would be to replace this line with a similar one, but
> > in which the units are under our control, and can be spelled out.
> 
> This could decrease performance, because you need to calculate the size
> of all files there.

Since a user option is being discussed, we could have this an opt-in
feature controlled by that option.  Since most users aren't annoyed by
the original value (as evidenced by the lack of complaints until now),
we can assume the few who are motivated to see a value with units will
agree to pay something in performance.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> >> My suggestion is to not display the line by default.  People who do find
>> >> it useful can switch it on (but I doubt they exist in large numbers).
>> >
>> > An alternative would be to replace this line with a similar one, but
>> > in which the units are under our control, and can be spelled out.
>>
>> This could decrease performance, because you need to calculate the size
>> of all files there.
>
> Since a user option is being discussed, we could have this an opt-in
> feature controlled by that option.  Since most users aren't annoyed by
> the original value (as evidenced by the lack of complaints until now),
> we can assume the few who are motivated to see a value with units will
> agree to pay something in performance.

Well, let's see how it goes. Tramp will follow the decisions.

Best regards, Michael.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Drew Adams]

> Maybe it could help to show some explanation with tooltips
> over cryptic parts of that line.

FWIW:

In my library ls-lisp+.el I use tooltips and links on
parts of that line, and the text for that line is a
bit different.  E.g.:

 files 1610/1610 space used 116754 available 101631612

There are two parts, with a tooltip each:

1. files 1610/1610
2. space used 116754 available 101631612

Tooltip for #1:
 Files shown / total files in directory [RET, mouse-2: more info]

Tooltip for #2:
 Kbytes used in directory, Kbytes available on disk [RET, mouse-2: more info]

Each part also has a link, which shows *Help* with
the `file-attributes' for the directory in tabular form.

bug#44273: "total used in directory 19 available 5.2 GiB"

[積丹尼 Dan Jacobson]

Yup. fellows, that line, it turns out is for old timers, from back in the
days when people discussed "disk space".

So it should be not shown by default, and if any old-timer wants to turn
it on, they can figure out what it means on their own. (Mention that in
the docs: "dired-display-ls-nerd-line: (or
dired-display-ls-statistics-line) default nil. Contains system specific
Nurd info beyond emacs' knowledge.)

Voila, lots of programming avoided.

As far as /usr/bin/ls: that's beyond the scope of this bug.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Yup. fellows, that line, it turns out is for old timers, from back in the
  > days when people discussed "disk space".

Please do not speak to others with that dismissive tone.
Please show respect to the people who disagree with you.
We all need to do that.

See https://gnu.org/philosophy/kind-communication.html.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#44273: "total used in directory 19 available 5.2 GiB"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Given that the units seem to be in general unknowable, what would you
  > suggest to say in that tooltip?

On GNU/Linux with GNU ls, the first number is measured in 1k blocks
unless options specify a different block size.

The second number is whatever is in the string that
get-free-disk-space returns.  That function has a hook with which you
can customize how to represent the amount of free space.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#44273: "total used in directory 19 available 5.2 GiB"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Because some people find it useful.

  > Do you have data to back that up?  :-)

The only data I have, the only data you have, is what a few
people say.  I sometimes use that information.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#44273: "total used in directory 19 available 5.2 GiB"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > An alternative would be to replace this line with a similar one, but
  > > in which the units are under our control, and can be spelled out.

  > This could decrease performance, because you need to calculate the size
  > of all files there. Think about a directory with several thousand
  > files, located remotely. And we don't have "du" for all Tramp backends.

The efficient way to do this is to know what units ls uses for the
total size, and convert that number to whatever unit is desired.

We could easily make nsert-directory call a hook to reformat
this information to delete it.  So there is no need to treat this
as a fight in which one side wins and others lose.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#44273: "total used in directory 19 available 5.2 GiB"

[Eli Zaretskii]

> Date: Wed, 28 Oct 2020 17:28:45 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: mattiase@acm.org, jidanni@jidanni.org, 44273@debbugs.gnu.org
> 
> Profiling ls-lisp could also be educational.  For example, I see in
> the profile on my system that this loop:
> 
> 	(let ((locale system-time-locale))
> 	  (if (not locale)
> 	      (let ((vars '("LC_ALL" "LC_TIME" "LANG")))
> 		(while (and vars (not (setq locale (getenv (car vars)))))
> 		  (setq vars (cdr vars)))))
> 
> is run for each file, which is definitely a waste of cycles.  My
> measurements indicate that running this loop just once could speed up
> ls-lisp by 25%.

I've now implemented that optimization on the master branch.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Juri Linkov]

>>> That's it's unknowable (or rather -- read the ls man page).
>>
>> Is that really a useful tooltip?
>
> Yes.
>
> But, like I said, it'd be better to remove the line.  It takes up
> valuable screen space for little use.

This line contains very useful information that I check all the time:
free disk space.  Also space used by directory could be useful when
displayed in a human-readable format like free space is already displayed.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Then I'm sorry, but I don't understand the logic here.  'ls' shows
> this "useless" information, and yet you don't think it should be
> removed from 'ls', and all the users of 'ls' evidently don't mind
> seeing it.  But in Emacs the same information is somehow not useful
> enough to be shown?  That doesn't add up.

I'm not involved with "ls" development, and I don't wish to be.
However, I am interested in making Emacs better.

I don't see why you find this to be a puzzling state of affairs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44273: "total used in directory 19 available 5.2 GiB"

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> This line contains very useful information that I check all the time:
> free disk space.

Yes, free disk space is nice to know, and could, for instance, be
displayed in the mode line (in dired mode buffers).

> Also space used by directory could be useful when displayed in a
> human-readable format like free space is already displayed.

It only displays the space used directly in the current directory, which
is (in general) not interesting information.  (I.e., it doesn't descend
into sub-directories and count the usage there, so in any directory that
has a sub-directory, the data is misleading at best.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44273: "total used in directory 19 available 5.2 GiB"

[Mattias Engdegård]

1 nov. 2020 kl. 12.38 skrev Lars Ingebrigtsen <larsi@gnus.org>:

> It only displays the space used directly in the current directory, which
> is (in general) not interesting information.  (I.e., it doesn't descend
> into sub-directories and count the usage there, so in any directory that
> has a sub-directory, the data is misleading at best.)

Right, and it's worse. Even if we knew exactly the unit used (sectors, kibibytes, imperial qubits), what we get for a subdirectory is still platform-dependent.

Except that it's worse than that. The semantics may vary between file-systems on a single machine.

Except that it's even worse. It may depend on the history of the subdirectory. For instance, it could be the maximum number of disk hardware sectors used for the internal representation of some of the metadata for that directory at any time in the past. (This is probably the original meaning of the number.)

bug#44273: "total used in directory 19 available 5.2 GiB"

[Eli Zaretskii]

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Sun, 1 Nov 2020 12:55:23 +0100
> Cc: Juri Linkov <juri@linkov.net>, Eli Zaretskii <eliz@gnu.org>, rms@gnu.org,
>         jidanni@jidanni.org, stefankangas@gmail.com, 44273@debbugs.gnu.org
> 
> 1 nov. 2020 kl. 12.38 skrev Lars Ingebrigtsen <larsi@gnus.org>:
> 
> > It only displays the space used directly in the current directory, which
> > is (in general) not interesting information.  (I.e., it doesn't descend
> > into sub-directories and count the usage there, so in any directory that
> > has a sub-directory, the data is misleading at best.)
> 
> Right, and it's worse. Even if we knew exactly the unit used (sectors, kibibytes, imperial qubits), what we get for a subdirectory is still platform-dependent.
> 
> Except that it's worse than that. The semantics may vary between file-systems on a single machine.
> 
> Except that it's even worse. It may depend on the history of the subdirectory. For instance, it could be the maximum number of disk hardware sectors used for the internal representation of some of the metadata for that directory at any time in the past. (This is probably the original meaning of the number.)

This actually means that this value provides information that is not
directly available in the file sizes.  So it is useful.

I find the notion that we should remove from display a useful quantity
just because it might be tricky to interpret in some situation,
especially by people who are not proficient in this stuff.  'ls' shows
it, and Dired isn't supposed to lose stuff that 'ls -al' provides.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Mattias Engdegård]

1 nov. 2020 kl. 16.21 skrev Eli Zaretskii <eliz@gnu.org>:

> This actually means that this value provides information that is not
> directly available in the file sizes.  So it is useful.

No and no: the information is available in the file sizes, but the 'file size' of a subdirectory is practically impossible to interpret in a useful way.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Eli Zaretskii]

> Feedback-ID:mattiase@acm.or
> From: Mattias Engdegård <mattiase@acm.org>
> Date: Sun, 1 Nov 2020 16:41:34 +0100
> Cc: larsi@gnus.org, juri@linkov.net, rms@gnu.org, jidanni@jidanni.org,
>         stefankangas@gmail.com, 44273@debbugs.gnu.org
> 
> 1 nov. 2020 kl. 16.21 skrev Eli Zaretskii <eliz@gnu.org>:
> 
> > This actually means that this value provides information that is not
> > directly available in the file sizes.  So it is useful.
> 
> No and no: the information is available in the file sizes

It isn't: that value shows the total disk space allocation, i.e. the
file sizes are rounded up to the nearest disk block size.

> but the 'file size' of a subdirectory is practically impossible to interpret in a useful way.

We are not talking about file sizes, we are talking about the "total
NNN" part.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Mattias Engdegård]

1 nov. 2020 kl. 16.51 skrev Eli Zaretskii <eliz@gnu.org>:

> It isn't: that value shows the total disk space allocation, i.e. the
> file sizes are rounded up to the nearest disk block size.

It's often not even the disk block size (frequently 512 or 1024 byte regardless of the block size), and in any case that rounding does not add any valuable information.

>> but the 'file size' of a subdirectory is practically impossible to interpret in a useful way.
> 
> We are not talking about file sizes, we are talking about the "total
> NNN" part.

The 'file size' of all displayed subdirectory entries are included in that number, which makes it even more difficult to interpret.

If the size field of each displayed entry could be accurately located and parsed, then that could be used to compose a more useful and defensible 'total' number. However this does not appear likely given the variation in locales, implementations and user-supplied options.

Given the opposition to removing the field, I propose that this bug be closed with wontfix (again). Let's use our time more productively.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-11-01 18:22]:
> This actually means that this value provides information that is not
> directly available in the file sizes.  So it is useful.
> 
> I find the notion that we should remove from display a useful quantity
> just because it might be tricky to interpret in some situation,
> especially by people who are not proficient in this stuff.  'ls' shows
> it, and Dired isn't supposed to lose stuff that 'ls -al' provides.

Instead of blocks users can set it up "human readable" with ls -alh
option or similar:

dired-listing-switches is a variable defined in ‘dired.el’.
Its value is "-gohl --group-directories-first"
Original value was "-al"

  You can customize this variable.

Then there is more practical display:

  total used in directory 1.4G available 24.8 GiB

bug#44273: "total used in directory 19 available 5.2 GiB"

[Jean Louis]

* Mattias Engdegård <mattiase@acm.org> [2020-11-01 18:42]:
> 1 nov. 2020 kl. 16.21 skrev Eli Zaretskii <eliz@gnu.org>:
> 
> > This actually means that this value provides information that is not
> > directly available in the file sizes.  So it is useful.
> 
> No and no: the information is available in the file sizes, but the
> 'file size' of a subdirectory is practically impossible to interpret
> in a useful way.

You may read the manual page for `ls' as `ls' output is displayed by
dired. What may not be usable to you at first sight, may be usable for
others. I have not been watching this detail you pointed out, but it
was always usable to see the free space on various partitions or
remote directories.

The manual page for GNU ls says:

	-k, --kibibytes
		default to 1024-byte blocks for disk usage

so if you write:

ls -la

or

ls -lka

You get same output as size of directory is shown in kibibytes.

Example:

 ls -l
total 4
lrwxrwxrwx 1 admin admin   37 Sep 22 23:41 Mobil -> /home/data1/protected/Downloads/Mobil
drwx------ 3 admin admin 4096 Aug 12 08:26 Old IceCat Data
lrwxrwxrwx 1 admin admin   21 Sep 30 02:06 protected -> /home/data1/protected

But if I see something like this:

ls -la |head 
total 1379484

then I know by watching the number it is about 1379 megabytes. I am
wrong because conversion tells me it is 1412 megabytes and 1347
mebibytes. But I have got a feeling of how much space files in the
directory occupy.

To make it more human friendly there is option -h that you may set in
variable `dired-listing-switches' and just add `h' somewhere with
`-al' together then you get something like:

ls -lha |head 
total 1.4G

You can set it by tweaking option `dired-listing-switches':

	--block-size=SIZE
		scale  sizes  by  SIZE   before  printing  them;  e.g.,
		'--block-size=M'  prints sizes  in  units of  1,048,576
		bytes; see SIZE format below

	The SIZE argument is an  integer and optional unit (example:
	10K is 10*1024).  Units are K,M,G,T,P,E,Z,Y (powers of 1024)
	or KB,MB,... (powers of 1000).

Dired will show you whatever you set for `ls'

Be happy to be on GNU based system, as ls will give you good usage
help with:

$ ls --help

while on BSD-like free software system like Dragonfly BSD you get
this (as there is no help option)

ls --help
ls: illegal option -- -
usage: ls [-1ABCFGHILPRSTW_abcdfghiklmnopqrstuwxy] [-D format] [file ...]


So it is not a bug, it is feature and some people may like to read it
in blocks of 1024 bytes and some may like in kilobytes or similar.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Jean Louis]

* Mattias Engdegård <mattiase@acm.org> [2020-11-01 19:38]:
> If the size field of each displayed entry could be accurately
> located and parsed, then that could be used to compose a more useful
> and defensible 'total' number. However this does not appear likely
> given the variation in locales, implementations and user-supplied
> options.

There exists Emacs package `dired-du' which may help you to see sizes
of subdirectories.

It will slow down system with many files but it work well for smaller.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Eli Zaretskii]

> Date: Sun, 1 Nov 2020 21:57:05 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: Mattias Engdegård <mattiase@acm.org>,
>   rms@gnu.org, juri@linkov.net, stefankangas@gmail.com, larsi@gnus.org,
>   jidanni@jidanni.org, 44273@debbugs.gnu.org
> 
> Instead of blocks users can set it up "human readable" with ls -alh
> option or similar:

I know.  But users who do that know what they did, so they will know
how to interpret the number.

bug#44273: "total used in directory 19 available 5.2 GiB"

[積丹尼 Dan Jacobson]

>>>>> "LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:

LI> Yes, free disk space is nice to know, and could, for instance, be
LI> displayed in the mode line (in dired mode buffers).

But for us with lots of money in the bank, there is no need for 24 hour
reminders of how much we have.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
> Cc: Juri Linkov <juri@linkov.net>,  Eli Zaretskii <eliz@gnu.org>,
>   rms@gnu.org,  mattiase@acm.org,  stefankangas@gmail.com,
>   44273@debbugs.gnu.org
> Date: Mon, 02 Nov 2020 03:38:03 +0800
> 
> >>>>> "LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> LI> Yes, free disk space is nice to know, and could, for instance, be
> LI> displayed in the mode line (in dired mode buffers).
> 
> But for us with lots of money in the bank, there is no need for 24 hour
> reminders of how much we have.

You have the freedom not to look at the number, then.

bug#44273: "total used in directory 19 available 5.2 GiB"

[積丹尼 Dan Jacobson]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
>> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
>> Cc: Juri Linkov <juri@linkov.net>,  Eli Zaretskii <eliz@gnu.org>,
>> rms@gnu.org,  mattiase@acm.org,  stefankangas@gmail.com,
>> 44273@debbugs.gnu.org
>> Date: Mon, 02 Nov 2020 03:38:03 +0800
>> 
>> >>>>> "LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:
>> 
LI> Yes, free disk space is nice to know, and could, for instance, be
LI> displayed in the mode line (in dired mode buffers).
                                ^^^^^^^^^^^^^^^^^^^^^ OK, it's a deal.
                                Speaking of deals, or the art of making
                                them, don't forget to vote for *****,
                                not *****, tomorrow.

>> But for us with lots of money in the bank, there is no need for 24 hour
>> reminders of how much we have.

EZ> You have the freedom not to look at the number, then.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Drew Adams]

> > Maybe it could help to show some explanation with tooltips
> > over cryptic parts of that line.
> 
> FWIW:
> 
> In my library ls-lisp+.el I use tooltips and links on
> parts of that line, and the text for that line is a
> bit different.  E.g.:
> 
>  files 1610/1610 space used 116754 available 101631612
> 
> There are two parts, with a tooltip each:
> 
> 1. files 1610/1610
> 2. space used 116754 available 101631612
> 
> Tooltip for #1:
>  Files shown / total files in directory [RET, mouse-2: more info]
> 
> Tooltip for #2:
>  Kbytes used in directory, Kbytes available on disk [RET, mouse-2: more info]
> 
> Each part also has a link, which shows *Help* with
> the `file-attributes' for the directory in tabular form.

FWIW, looking for something else I came across this
emacs-develpost from 2016, which also talks about
"files N/M", i.e., showing the number of files that 
are currently listed and the total number of files
(including hidden/omitted):

https://lists.gnu.org/archive/html/emacs-devel/2016-09/msg00277.html

bug#44273: "total used in directory 19 available 5.2 GiB"

[Juri Linkov]

> FWIW, looking for something else I came across this
> emacs-develpost from 2016, which also talks about
> "files N/M", i.e., showing the number of files that
> are currently listed and the total number of files
> (including hidden/omitted):

And maybe also show the number of marked/flagged files,
updated on every marking/unmarking.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Drew Adams]

> > FWIW, looking for something else I came across this
> > emacs-develpost from 2016, which also talks about
> > "files N/M", i.e., showing the number of files that
> > are currently listed and the total number of files
> > (including hidden/omitted):
> 
> And maybe also show the number of marked/flagged files,
> updated on every marking/unmarking.

IMO, that's better done in the mode line, which is what
Dired+ does.

The "total" line we're talking about, for each subdir
listing, shows the # of visible files for that subdir
listing and the total # of files in the top-level dir
of the buffer.

The mode line shows Dired/date or Dired/name, and the
# of marks (*) and # of flags (D).  And it shows the
ordinal # of the file or dir on the current line (point),
with the current sorting, as well as the total number of
files/dirs for that subdir listing.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Juri Linkov]

>> > FWIW, looking for something else I came across this
>> > emacs-develpost from 2016, which also talks about
>> > "files N/M", i.e., showing the number of files that
>> > are currently listed and the total number of files
>> > (including hidden/omitted):
>>
>> And maybe also show the number of marked/flagged files,
>> updated on every marking/unmarking.
>
> IMO, that's better done in the mode line, which is what
> Dired+ does.
>
> The "total" line we're talking about, for each subdir
> listing, shows the # of visible files for that subdir
> listing and the total # of files in the top-level dir
> of the buffer.
>
> The mode line shows Dired/date or Dired/name, and the
> # of marks (*) and # of flags (D).  And it shows the
> ordinal # of the file or dir on the current line (point),
> with the current sorting, as well as the total number of
> files/dirs for that subdir listing.

Another variant is that marking/unmarking commands could show
a message in the echo area with statistics of marked/flagged files
with total sizes of all marked/flagged files.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Drew Adams]

> >> And maybe also show the number of marked/flagged files,
> >> updated on every marking/unmarking.
> >
> > IMO, that's better done in the mode line, which is what
> > Dired+ does.
> >
> > The "total" line we're talking about, for each subdir
> > listing, shows the # of visible files for that subdir
> > listing and the total # of files in the top-level dir
> > of the buffer.
> >
> > The mode line shows Dired/date or Dired/name, and the
> > # of marks (*) and # of flags (D).  And it shows the
> > ordinal # of the file or dir on the current line (point),
> > with the current sorting, as well as the total number of
> > files/dirs for that subdir listing.
> 
> Another variant is that marking/unmarking commands could show
> a message in the echo area with statistics of marked/flagged files
> with total sizes of all marked/flagged files.

IMO that would constitute unnecessary noise.

That would be the case even if it just said part of that.
But it would be especially noisy to include not only mark
and flag tallies but also file sizes.

We echo the result of an actual action (e.g. "Copy: 1 file").
I don't think it would be a good idea to echo (un)marking
or (un)flagging actions.

In any case, that would not substitute for having a tally
of marks and flags shown constantly, which you can refer
to at any time.

bug#44273: "total used in directory 19 available 5.2 GiB"

[Stefan Kangas]

tags 44273 + wontfix
close 44273
thanks

Mattias Engdegård <mattiase@acm.org> writes:

> 1 nov. 2020 kl. 16.51 skrev Eli Zaretskii <eliz@gnu.org>:
>
>> It isn't: that value shows the total disk space allocation, i.e. the
>> file sizes are rounded up to the nearest disk block size.
>
> It's often not even the disk block size (frequently 512 or 1024 byte regardless of the block size), and in any case that rounding does not add any valuable information.
>
>>> but the 'file size' of a subdirectory is practically impossible to interpret in a useful way.
>>
>> We are not talking about file sizes, we are talking about the "total
>> NNN" part.
>
> The 'file size' of all displayed subdirectory entries are included in that number, which makes it even more difficult to interpret.
>
> If the size field of each displayed entry could be accurately located and
> parsed, then that could be used to compose a more useful and defensible 'total'
> number. However this does not appear likely given the variation in locales,
> implementations and user-supplied options.
>
> Given the opposition to removing the field, I propose that this bug be closed with wontfix (again). Let's use our time more productively.

OK, let's do that.