Re: master 2b97e83cc1 2/2: Fix off-by-one file size formatting in ls-lisp

Re: master 2b97e83cc1 2/2: Fix off-by-one file size formatting in ls-lisp

[Stefan Monnier]

>     * lisp/ls-lisp.el (ls-lisp-format, ls-lisp-format-file-size): The
>     human-readable file sizes can be 7 characters wide (e.g.,
>     "1016.1k") (bug#53937).

Why would we want the ".1" in "1016.1k"?


        Stefan

Re: master 2b97e83cc1 2/2: Fix off-by-one file size formatting in ls-lisp

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>     * lisp/ls-lisp.el (ls-lisp-format, ls-lisp-format-file-size): The
>>     human-readable file sizes can be 7 characters wide (e.g.,
>>     "1016.1k") (bug#53937).
>
> Why would we want the ".1" in "1016.1k"?

Perhaps we don't.  For a file like

  -rw-r--r--  1 larsi      larsi       1029204 Feb 12 08:04 bytes

ls-lisp displays

-rw-r--r--  1 larsi      larsi      1005.1k Feb 12 08:04 bytes

and ls displays

  -rw-r--r--  1 larsi      larsi      1006K Feb 12 08:04 bytes

with "-lh".

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

Re: master 2b97e83cc1 2/2: Fix off-by-one file size formatting in ls-lisp

[Stefan Monnier]

>> Why would we want the ".1" in "1016.1k"?
> Perhaps we don't.

I don't know what's "generally accepted" but personally I find
a 1% accuracy to be perfectly sufficient, and I think if someone needs
more than 0.1% accuracy there's a good chance they'd be just as happy with
"full" accuracy.

My "ideal" balance between screen real-estate and accuracy is
3 characters, i.e. " 23", "178", "980", " 1.2", followed by the
µ/m/k/M/G/... scaling factor and units.

Maybe I'm on the "low-accuracy" range of people, so I can see good
reasons to prefer 4 characters instead, but 6 as above seems hard
to justify.


        Stefan

Re: master 2b97e83cc1 2/2: Fix off-by-one file size formatting in ls-lisp

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sat, 12 Feb 2022 12:25:51 -0500
> 
> >     * lisp/ls-lisp.el (ls-lisp-format, ls-lisp-format-file-size): The
> >     human-readable file sizes can be 7 characters wide (e.g.,
> >     "1016.1k") (bug#53937).
> 
> Why would we want the ".1" in "1016.1k"?

See file-size-human-readable.  (IOW, this has nothing to do with
ls-lisp.)

Re: master 2b97e83cc1 2/2: Fix off-by-one file size formatting in ls-lisp

[Stefan Monnier]

>> >     * lisp/ls-lisp.el (ls-lisp-format, ls-lisp-format-file-size): The
>> >     human-readable file sizes can be 7 characters wide (e.g.,
>> >     "1016.1k") (bug#53937).
>> 
>> Why would we want the ".1" in "1016.1k"?
>
> See file-size-human-readable.

I know.  And I'm asking why `file-size-human-readable` gives so
much accuracy.

> (IOW, this has nothing to do with ls-lisp.)

Agreed.


        Stefan

Re: master 2b97e83cc1 2/2: Fix off-by-one file size formatting in ls-lisp

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org,  larsi@gnus.org
> Date: Sat, 12 Feb 2022 14:15:54 -0500
> 
> >> >     * lisp/ls-lisp.el (ls-lisp-format, ls-lisp-format-file-size): The
> >> >     human-readable file sizes can be 7 characters wide (e.g.,
> >> >     "1016.1k") (bug#53937).
> >> 
> >> Why would we want the ".1" in "1016.1k"?
> >
> > See file-size-human-readable.
> 
> I know.  And I'm asking why `file-size-human-readable` gives so
> much accuracy.

It's a feature:

      (format (if (and (>= (mod file-size 1.0) 0.05)
                       (< (mod file-size 1.0) 0.95))
		  "%.1f%s%s"
	        "%.0f%s%s")

Re: master 2b97e83cc1 2/2: Fix off-by-one file size formatting in ls-lisp

[Stefan Monnier]

>> I know.  And I'm asking why `file-size-human-readable` gives so
>> much accuracy.
>
> It's a feature:
>
>       (format (if (and (>= (mod file-size 1.0) 0.05)
>                        (< (mod file-size 1.0) 0.95))
> 		  "%.1f%s%s"
> 	        "%.0f%s%s")

Why is it a feature to waste those two perfect good characters on such
irrelevant details?


        Stefan

Re: master 2b97e83cc1 2/2: Fix off-by-one file size formatting in ls-lisp

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org,  larsi@gnus.org
> Date: Sat, 12 Feb 2022 14:42:07 -0500
> 
> >> I know.  And I'm asking why `file-size-human-readable` gives so
> >> much accuracy.
> >
> > It's a feature:
> >
> >       (format (if (and (>= (mod file-size 1.0) 0.05)
> >                        (< (mod file-size 1.0) 0.95))
> > 		  "%.1f%s%s"
> > 	        "%.0f%s%s")
> 
> Why is it a feature

It's a feature by definition: there's code that intentionally does
that.

> to waste those two perfect good characters on such irrelevant
> details?

A feature doesn't have to be liked to be a feature.

Re: master 2b97e83cc1 2/2: Fix off-by-one file size formatting in ls-lisp

[Stefan Monnier]

>> >> I know.  And I'm asking why `file-size-human-readable` gives so
>> >> much accuracy.
>> >
>> > It's a feature:
>> >
>> >       (format (if (and (>= (mod file-size 1.0) 0.05)
>> >                        (< (mod file-size 1.0) 0.95))
>> > 		  "%.1f%s%s"
>> > 	        "%.0f%s%s")
>> 
>> Why is it a feature
>
> It's a feature by definition: there's code that intentionally does
> that.
>
>> to waste those two perfect good characters on such irrelevant
>> details?
>
> A feature doesn't have to be liked to be a feature.

No, but if we don't like it we can remove it.
Do you find this feature useful?  If so, can you give me an idea what
you like about it?


        Stefan

Re: master 2b97e83cc1 2/2: Fix off-by-one file size formatting in ls-lisp

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org,  larsi@gnus.org
> Date: Sat, 12 Feb 2022 15:32:16 -0500
> 
> >> >       (format (if (and (>= (mod file-size 1.0) 0.05)
> >> >                        (< (mod file-size 1.0) 0.95))
> >> > 		  "%.1f%s%s"
> >> > 	        "%.0f%s%s")
> >> 
> >> Why is it a feature
> >
> > It's a feature by definition: there's code that intentionally does
> > that.
> >
> >> to waste those two perfect good characters on such irrelevant
> >> details?
> >
> > A feature doesn't have to be liked to be a feature.
> 
> No, but if we don't like it we can remove it.
> Do you find this feature useful?  If so, can you give me an idea what
> you like about it?

AFAIU, it attempts to show more significant digits when the value is
near a round power.

Re: master 2b97e83cc1 2/2: Fix off-by-one file size formatting in ls-lisp

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> AFAIU, it attempts to show more significant digits when the value is
> near a round power.

Looks like it was introduced by this:

commit 04f33f1ed9cdfed6a3e44a55d333cd19d58424ca
Author:     Eli Zaretskii <eliz@gnu.org>
AuthorDate: Sat Apr 9 09:59:26 2011 +0300

    Produce more accurate results from file-size-human-readable.
    
     lisp/files.el (file-size-human-readable): Produce one digit after
     decimal, like "ls -lh" does.

But ls -lh does not use a digit after the decimal in this case.  At
least now -- perhaps it did in 2011?  On Debian/bookworm:

larsi@giant:~/src/emacs/trunk$ ls -lh /tmp/bytes
-rw-r--r-- 1 larsi larsi 1006K Feb 12 08:04 /tmp/bytes


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

Re: master 2b97e83cc1 2/2: Fix off-by-one file size formatting in ls-lisp

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> Date: Sun, 13 Feb 2022 09:28:53 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > AFAIU, it attempts to show more significant digits when the value is
> > near a round power.
> 
> Looks like it was introduced by this:
> 
> commit 04f33f1ed9cdfed6a3e44a55d333cd19d58424ca
> Author:     Eli Zaretskii <eliz@gnu.org>
> AuthorDate: Sat Apr 9 09:59:26 2011 +0300
> 
>     Produce more accurate results from file-size-human-readable.
>     
>      lisp/files.el (file-size-human-readable): Produce one digit after
>      decimal, like "ls -lh" does.
> 
> But ls -lh does not use a digit after the decimal in this case.  At
> least now -- perhaps it did in 2011?  On Debian/bookworm:
> 
> larsi@giant:~/src/emacs/trunk$ ls -lh /tmp/bytes
> -rw-r--r-- 1 larsi larsi 1006K Feb 12 08:04 /tmp/bytes

Neither does ls-lisp:

  -rw-rw-rw-  1 Zaretskii  1006k 02-13 14:07 test-of-ls.size.txt

I don't think we reproduce the original bug report.  It said:

  -rw-r--r--  1 salutis 1016.1k 12-23 17:05 default

and I don't think we know how many bytes that file actually had.
Rudolf, can you tell us how large was that file in bytes?

Re: master 2b97e83cc1 2/2: Fix off-by-one file size formatting in ls-lisp

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Neither does ls-lisp:
>
>   -rw-rw-rw-  1 Zaretskii  1006k 02-13 14:07 test-of-ls.size.txt
>
> I don't think we reproduce the original bug report.  It said:
>
>   -rw-r--r--  1 salutis 1016.1k 12-23 17:05 default

Like I said in an earlier post, my test file is 1029204 bytes.

(file-size-human-readable 1029204)
-> "1005.1k"

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

Re: master 2b97e83cc1 2/2: Fix off-by-one file size formatting in ls-lisp

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Rudolf Adamkovič <salutis@me.com>,
>   monnier@iro.umontreal.ca,
>   emacs-devel@gnu.org
> Date: Sun, 13 Feb 2022 13:36:50 +0100
> 
> Like I said in an earlier post, my test file is 1029204 bytes.
> 
> (file-size-human-readable 1029204)
> -> "1005.1k"

Ah, okay.  So you want to lose accuracy in these cases and just throw
away the fractional part?  Why?

I'm quite sure "ls -lh" still does that, albeit perhaps not with this
specific size.

Re: master 2b97e83cc1 2/2: Fix off-by-one file size formatting in ls-lisp

[Eli Zaretskii]

> Date: Sun, 13 Feb 2022 14:55:09 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: salutis@me.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Cc: Rudolf Adamkovič <salutis@me.com>,
> >   monnier@iro.umontreal.ca,
> >   emacs-devel@gnu.org
> > Date: Sun, 13 Feb 2022 13:36:50 +0100
> > 
> > Like I said in an earlier post, my test file is 1029204 bytes.
> > 
> > (file-size-human-readable 1029204)
> > -> "1005.1k"
> 
> Ah, okay.  So you want to lose accuracy in these cases and just throw
> away the fractional part?  Why?
> 
> I'm quite sure "ls -lh" still does that, albeit perhaps not with this
> specific size.

For example, with these sizes:

  1124 => 1.1K
  4939 => 4.9K
  8255 => 8.1K
  1188708 => 1.2M
  6916144 => 6.6M

So how about the patch below:

diff --git a/lisp/files.el b/lisp/files.el
index cfa1a59..7e62726 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -1494,7 +1494,8 @@ file-size-human-readable
                                (or unit "B"))
                             (concat prefix unit))))
       (format (if (and (>= (mod file-size 1.0) 0.05)
-                       (< (mod file-size 1.0) 0.95))
+                       (< (mod file-size 1.0) 0.95)
+                       (< file-size 10))
 		  "%.1f%s%s"
 	        "%.0f%s%s")
 	      file-size

Re: master 2b97e83cc1 2/2: Fix off-by-one file size formatting in ls-lisp

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> So how about the patch below:
>
> diff --git a/lisp/files.el b/lisp/files.el
> index cfa1a59..7e62726 100644
> --- a/lisp/files.el
> +++ b/lisp/files.el
> @@ -1494,7 +1494,8 @@ file-size-human-readable
>                                 (or unit "B"))
>                              (concat prefix unit))))
>        (format (if (and (>= (mod file-size 1.0) 0.05)
> -                       (< (mod file-size 1.0) 0.95))
> +                       (< (mod file-size 1.0) 0.95)
> +                       (< file-size 10))

Possibly, but it's hard to tell...  perhaps a better test is whether the
printed representation is longer than 6 characters, and then precision
should be reduced.

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

Re: master 2b97e83cc1 2/2: Fix off-by-one file size formatting in ls-lisp

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: salutis@me.com,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Mon, 14 Feb 2022 11:48:42 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > So how about the patch below:
> >
> > diff --git a/lisp/files.el b/lisp/files.el
> > index cfa1a59..7e62726 100644
> > --- a/lisp/files.el
> > +++ b/lisp/files.el
> > @@ -1494,7 +1494,8 @@ file-size-human-readable
> >                                 (or unit "B"))
> >                              (concat prefix unit))))
> >        (format (if (and (>= (mod file-size 1.0) 0.05)
> > -                       (< (mod file-size 1.0) 0.95))
> > +                       (< (mod file-size 1.0) 0.95)
> > +                       (< file-size 10))
> 
> Possibly, but it's hard to tell...  perhaps a better test is whether the
> printed representation is longer than 6 characters, and then precision
> should be reduced.

I thought we wanted to mimic what GNU 'ls' does?  AFAICT, it shows the
fractional part only for values whose integral part is less than 10,
i.e. takes just one digit.  So that's what the above change does.

If you run "ls -lh" on a large directory, do you see something
different from my description above?

Re: master 2b97e83cc1 2/2: Fix off-by-one file size formatting in ls-lisp

[Stefan Monnier]

> I thought we wanted to mimic what GNU 'ls' does?

Ahhhh!  So that's the answer to the "why" of this "feature".
Thanks,


        Stefan

Re: master 2b97e83cc1 2/2: Fix off-by-one file size formatting in ls-lisp

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I thought we wanted to mimic what GNU 'ls' does?  AFAICT, it shows the
> fractional part only for values whose integral part is less than 10,
> i.e. takes just one digit.  So that's what the above change does.

Ah, right, I misread the patch.  Then that looks good to me.

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

Re: master 2b97e83cc1 2/2: Fix off-by-one file size formatting in ls-lisp

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: salutis@me.com,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Mon, 14 Feb 2022 15:20:43 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I thought we wanted to mimic what GNU 'ls' does?  AFAICT, it shows the
> > fractional part only for values whose integral part is less than 10,
> > i.e. takes just one digit.  So that's what the above change does.
> 
> Ah, right, I misread the patch.  Then that looks good to me.

Thanks, installed.

Re: master 2b97e83cc1 2/2: Fix off-by-one file size formatting in ls-lisp

[Rudolf Adamkovič]

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks, installed.

Thank you everyone!  I can confirm that I now see perfectly aligned
directory listings in Dired, like with the native 'ls'.

Rudy
-- 
"Mathematics takes us still further from what is human into the region
of absolute necessity, to which not only the actual world, but every
possible world, must conform."
-- Bertrand Russell, 1902

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia