bug#22536: guix lint

[Danny Milosavljevic]

> There may other places to fix, see <http://bugs.gnu.org/22536>.

Yeah, there's one at guix/build/download.scm in function "progress-proc". 

I checked what "string-pad-middle" - which is used by the function 
"progress-proc" - does and I... object to it in priciple. 

What it does is add padding (in the middle) in order to make a string at least 
a certain length (sometimes more!).

So we have:

>>> (string-pad-middle "http://foo"; "bar 34 B/s" 80)
"http://foo                                                        bar 34 B/s"

Arguments against it are (o: questionable mitigation, leaning heavily against; 
*: against it with OK mitigation; X: definitely against it):
o The terminal width is not passed to it correctly (can be fixed, although I 
have to read up on what the currently recommeded way is. tcgetattr ?).
o The terminal width can change while the script is running (can this be fixed? 
It would need a SIGWINCH handler and some kind of notification to 
scripts/download so it reprints the progress text). Now you can have a race 
between (1) and (2), fun.
* The terminal width can be changed after the script is done and has printed 
its thing (nobody can fix the output up anymore). In our present case, the text 
is supposedly ephemeral, so it shouldn't be there anymore, so it's fine.
o Since it uses string-length it doesn't actually count how many glyphs would 
be printed on the terminal, while it should do so (this can be fixed - but at 
large complexity increase and as long as the terminal doesn't use 
variable-width fonts; arguably if it's documented to be only used for ASCII 
strings it's simple. We should probably do the latter - and never translate it 
into another human language).
o The resulting string can be longer than what it was told to (can be fixed - 
although what should it cut off first then? The first or the second string? the 
first string is the (abbreviate file) and the second string contains 
transferred amount, speed etc).
* Overengineering helps no one. If the terminal is not wide enough, let the 
user resize it or the terminal handler virtual-word-wrap it or whatever instead 
of this abbreviation business. Anything but every program guessing how wide the 
tty is at some random point in time. Many GNU tools do the latter and I wish 
they would stop it and just print the entire thing. Because the progress is 
ephemeral (it's replaced by a new paragraph every time), this argument is not 
so strong here.
o Having this maximal padding in-between means that if we misjudge the glyph 
width, it will certainly mess up the display. While if we didn't have this 
padding, the error would often not manifest as failure (if there's enough free 
space left anyway). Why do it?

Any more arguments for or against it?

I can also fix up string-pad-middle while maintaining its way, but just for the 
record, this is a bad way of doing it.

If we are concerned about all emphemeral "transferred" lines lining up, just 
print the speed first (with fixed width, if possible) and the URL afterwards, 
with one space in-between.

We could abbreviate it if we have to - but should the download fail, the error 
message then has to contain the unabbreviated URL for usability (note: it 
does). At that point, why have the URL in the download progress at all? Total 
percentage done (over all the downloads) would be a lot more useful.

If we do print a table, I would suggest setting a tab stop (using ESC H or 
similar) and using the tab character to print tables - that's what they are 
for. Note: there's a standalone "column -t" tool which also does the right 
thing, apparently.

Also, is there a control character which returns to the beginning of the 
paragraph? Double-clicking on a paragraph in gnome-terminal selects the entire 
paragraph - so it does know what extent the paragraph has. However, printing CR 
returns me to the beginning of the row, not the beginning of the paragraph.

The terminal could be such a nice universal text interface - if programs don't 
have to know presentation details like how wide the terminal is currently. Why 
should a program have to care? *shakes head*