Format the filesize in status bar at the bottom about lf HOT 16 CLOSED

After the tiny update with aligning, I noticed, that bytes are not designated with B which still causes the "flickering". Except for the decimal precision, would you also slightly extend the humanize() function to produce B for bytes?

from lf.

@dumblob There is no B for bytes since I was thinking this way humanize() would be a general function. It is only used for file sizes for now so I guess we can add the B character but then it would make more sense to change K to KB and so on. That would just add a mostly redundant character without any benefits. Current implementation is brief and it is the way GNU ls works and I think it makes sense.

I don't quite understand what you mean by "flickering". Without having same values for sizes you would always have a flickering. Whether you have B or not shouldn't make any difference. And if you're just sweeping over files to see their sizes, I think it makes sense to use set showinfo size instead. I think it would be better to discuss what concrete problem you have instead of requesting changes so we can do a brainstorm and come up with a common solution.

from lf.

Understood, if B is not desired, would it be possible to put to the resulting string a space character in case it's just bytes? If not directly to humanize(), then probably in loadFileInfo() like this:

var x := curr.Size()
if x[len(x)-1] >= "0"[0] && x[len(x)-1] <= "9"[0] {
  x += " "  // "B" might be even better than " "
}
ui.message = fmt.Sprintf("%v %4s %v", curr.Mode(), x, curr.ModTime().Format(gOpts.timefmt))

(len(x) is cached by Go, so it's not computed twice; but anyway, it doesn't matter for those very few characters humanize() returns)

The "flickering" is otherwise gone, because the aligning to 4 characters is in all cases enough.

And if you're just sweeping over files to see their sizes, I think it makes sense to use set showinfo size instead.

It's not about seeing sizes, but about "flickering" in general - I'm overly sensitive to any unwanted or unneeded distractions happening on my screen. The code above will reduce the overall flickering.

from lf.

@dumblob It's not difficult to add an extra character but I don't see the point. I still don't understand what you mean by flickering. I'm beginning to wonder if you have a bug that I can't reproduce. Can you maybe give some example statusline content as you did before and clearly explain what flickers?

from lf.

Hi @gokcehan, don't worry, it's not a bug. It's just the fact, that while browsing files (frequently including among other things also so short sweeps, that it would be thrice as slow to select the files, run an own command listing the required information, first then reading this list through from the beginning, closing this list and finally navigating to the chosen file) my eyes are used to fixed-width columns as these are way easier to follow than variable widths.

If I want to look quickly at any part of the line at the bottom, I'll take a look precisely at the character the particular column starts with. And if one wants to e.g. find quickly a particular date or size in a small amount of files (which is the most common case), I'm "sweeping" over those e.g. 8 files. But if each second file has size less than 1KB, then I can't with my eyes look at the particular column, but need to step very slowly and refocus my eyes for each file - this issue I call "flickering" as I couldn't find a better term for it.

So it's just about speed of file browsing - for very slow browsing there is no "flickering". For faster browsing (which I prefer - I use keyboard key repeat frequency significantly higher than the default one) it kinda "flickers" and tires my eyes.

from lf.

@dumblob I partly understand the problem, I just don't see how your suggestion solves it. Consider the following example:

1.2M
 12K
121K
5.1K
  28
   5
 114

And you're suggesting we should do instead:

1.2M
 12K
121K
5.1K
 28B
  5B
114B

Now can you say which column you want to focus your eye on?

from lf.

I think what he means is that in the second example, you know for a fact that the last column is always a unit and not part of the number. I'd tend to agree that this makes it a bit easier to stay focused on the "what's number, what's unit" part.
See that ranger goes even further here and prepends unit with a space, e.g.

1.2 M
 12 K
121 K
5.1 K
 28 B
  5 B
114 B

Edit: I think that the term "flickering" is what got as off here. It is usually used to describe situation when text disappears for a split second, then appears again. Which is not the case here. I don't know how to call it either, though ;-).

from lf.

Now can you say which column you want to focus your eye on?

Oh, now I understand your concern. It's simple:

1. There are only very few "groups" (B, K, M, G, T, P) which can appear at the end (currently it's though K, M, G, T, P, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 - i.e. way more and unpleasantly inconsistent as the numerals are not even close to the sizes the unit groups designate) and which quite closely separate the files into groups which in a small random set of files (which I sweep through) enough exactly identify a specific file - so the orientation is really great just based on these unit groups.

2. The length of the string (which is well visible without reading the number, because the preceding space made of space characters is clear enough) further makes the file identification (from the eye's point of view) basically perfectly distinguishable (it happens rarely that files in the same directory have their size so close - based on my experience this happens with files smaller than the disk block size).

And yes, @KenjiTakahashi is right with what I mean 😉.

from lf.

Ok so I have run some tests to remember what original rationale I had when I implemented this.

This is how GNU ls works (has two different modes):

gokce@ext:/tmp/asd$ ls -lv -h
total 4.9M
-rw-rw-r-- 1 gokce gokce  999 Jan  8 18:56 999.txt
-rw-rw-r-- 1 gokce gokce 1000 Jan  8 18:56 1000.txt
-rw-rw-r-- 1 gokce gokce 1001 Jan  8 18:56 1001.txt
-rw-rw-r-- 1 gokce gokce 1023 Jan  8 18:56 1023.txt
-rw-rw-r-- 1 gokce gokce 1.1K Jan  8 18:56 1025.txt
-rw-rw-r-- 1 gokce gokce 977K Jan  8 18:56 999999.txt
-rw-rw-r-- 1 gokce gokce 977K Jan  8 18:56 1000000.txt
-rw-rw-r-- 1 gokce gokce 977K Jan  8 18:56 1000001.txt
-rw-rw-r-- 1 gokce gokce 1.0M Jan  8 18:56 1048575.txt
-rw-rw-r-- 1 gokce gokce 1.1M Jan  8 18:56 1048577.txt
gokce@ext:/tmp/asd$ ls -lv --si
total 5.2M
-rw-rw-r-- 1 gokce gokce  999 Jan  8 18:56 999.txt
-rw-rw-r-- 1 gokce gokce 1.0k Jan  8 18:56 1000.txt
-rw-rw-r-- 1 gokce gokce 1.1k Jan  8 18:56 1001.txt
-rw-rw-r-- 1 gokce gokce 1.1k Jan  8 18:56 1023.txt
-rw-rw-r-- 1 gokce gokce 1.1k Jan  8 18:56 1025.txt
-rw-rw-r-- 1 gokce gokce 1.0M Jan  8 18:56 999999.txt
-rw-rw-r-- 1 gokce gokce 1.0M Jan  8 18:56 1000000.txt
-rw-rw-r-- 1 gokce gokce 1.1M Jan  8 18:56 1000001.txt
-rw-rw-r-- 1 gokce gokce 1.1M Jan  8 18:56 1048575.txt
-rw-rw-r-- 1 gokce gokce 1.1M Jan  8 18:56 1048577.txt

And ranger for the same files:

999.txt                   999 B
1000.txt                 1000 B
1001.txt                 1001 B
1023.txt                 1023 B
1025.txt                    1 K
999999.txt                977 K
1000000.txt               977 K
1000001.txt               977 K
1048575.txt              1024 K
1048577.txt                 1 M

And lastly lf for the same files:

999.txt                 999
1000.txt               1.0K
1001.txt               1.0K
1023.txt               1.0K
1025.txt               1.0K
999999.txt             999K
1000000.txt            1.0M
1000001.txt            1.0M
1048575.txt            1.0M
1048577.txt            1.0M

I remember I was trying to minimize the maximum amount space used while utilizing most of it so I mostly implemented the ls behavior. I also wanted to be consistent with inaccuracies, so I rounded down values and used metric suffixes instead of binary suffixes. Currently maximum number of characters is 4. Anything over 999 is a K so we have one space for a B character. I think ls skips B character since it doesn't use K for range 1000-1023 and somehow doesn't do this for M and over.

To sum up, I think we're ok to add a B character at the end. @dumblob @KenjiTakahashi

from lf.

Thanks a lot @gokcehan!

Back to the original issue - I'd also like to have the possibility (configurable option?) to see the fractional part of the size, because the big units (G, T, P) are usually indirectly "related" to some external contraint (DVD size, network bandwidth, upload size, DB entry size, etc.) and 4G is quite different in these terms from 4.599G or 4.012G or 4.999G. It should actually be pretty straightforward to add dot and 3 fractional numbers and make this configurable. Though I'd like to first hear your opinion on this issue of an indirect "relation".

from lf.

@dumblob Currently we always show the first significant digit for numbers with a single digit. So 4G never exists. Instead it is 4.5G, 4.0G, or 4.9G in your examples. For numbers with more than one digit, fraction is thrown away. The idea is that if you have a number more than 10, then it's less likely that the fraction matters. As I said above, this implementation is to limit the maximum number of characters required to show sizes. If you need more accuracy, I don't think it's good to rely on humanized forms anyway. Difference between binary and metric suffixes starts to be misleading after M and G in combination with rounding numbers up and down. In these cases, best option would be to disable humanization which we might add at some point. But then it will definitely flicker and I'm guessing you won't be happy about it.

from lf.

In these cases, best option would be to disable humanization which we might add at some point. But then it will definitely flicker and I'm guessing you won't be happy about it.

Making humanization optional would actually make sense as the numbers could be easily visually (with an eye) compared by their length (there should be some separator used for thousands - probably dictated by localization and LC_* environment variables) and the minimal column width could be computed based on sizes of all files in the given directory (yes, I would prefer waiting a second for the status line to "load" in comparison to flickering - the navigation in the file tree must stay though responsive, so the status line would need to be asynchronous which is exactly what Go was designed for).

from lf.

@dumblob I feel like the more we talk, the more this issue changes, as if we're obligated to change something about this and trying to figure out what it is. As I said, we might add an option to disable humanized sizes at some point but then why should the regular form have those features you mention. Humanized form should already cover most cases, the rest should be for rare occasions. Checking localization and such just to decide a digit separator sounds like the perfect example for over engineering. There needs to be a strong motivation to implement such things, however I can't even think of a case where humanization needs to be disabled.

If you ask me, it's best to hold this issue for a while until we figure out if there is any real limitation of the current implementation. In the meantime, this issue will remain open here, and you can report what concrete problems you come across in your daily use. What I mean is things like "I was trying to decide a tar file would fit to a dvd or not, and then..." instead of trying to imagine use cases. And it would be nice if you can also clearly state why set showinfo size or set sortby size does not work for your case. Obviously, we can't cover all possible cases we can imagine and there would be no point in doing so anyway. When we have something concrete, it would really motivate the person who is going to work on the implementation and maintenance.

from lf.

@gokcehan sure, making humanization optional is just an icing on the cake (and yes, I run into this issue rarely - but I can remember one case, when I was for several months working with scientific results consisting of hundreds of files whose sizes were very important and often only slightly different; that was actually the only case when I would switch humanization off).

Why do I propose this "insignificant" at the first glance feature? Because I'm convinced that technology should always provide means to solve my problem (which I already encountered) if it's possible to implement it with moderate resources investment. And this sounds to me exactly as the case. But I fully respect your opinion, because you, the creator, have your own vision of how lf should evolve and therefore I'm first discussing it here instead of directly pushing PRs or even making a separate fork (which I would like to avoid even at the expense that e.g. this file size precision will never be implemented).

And it would be nice if you can also clearly state why set showinfo size or set sortby size does not work for your case.

Most of my time I work on my 15" laptop (soon probably 14" 😢) and use a little bit higher DPI as tiny fonts are eye tiring. I've experimented with just two column UI (ratios) in lf and sizes shown next to file names, but the lost third column made lf hardly usable for navigation. So the answer is: due to space constraints.
With regards to set sortby size, I'm missing the glimpse of the size difference which prevents me to use it.

So for the time being, it's totally OK to keep the current state of lf in case you don't share my very own opinion on what should technology solve with moderate resources investment. Once I come across the need for full precision file sizes (i.e. humanization off), I'll come back to this issue 😉.

from lf.

Hi, a while ago I wrote this function with similar purpose: https://github.com/brualan/qr-filetransfer/commit/ed2dcc33df72bc25914fdc3b9fc3735ee05fbadb#diff-3f1ad41879763caf285707f64678af17R162

It's readable and also should be a bit faster than current implementation. I'd like to create a PR. So, what way of formatting is better to use, GNU or ranger?

from lf.

@brualan Thank you for your interest in contributing but I fail to see the purpose of such a patch. We already have a working implementation for this. Is there a problem with the current implementation? Blind optimizations are usually not a good idea. Do you have a sample workload that shows humanize at the top in the profiler?

from lf.