bug#22536: guix lint

[Ludovic Courtès]

Danny Milosavljevic <address@hidden> skribis:

>>>> (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.

Unfortunately, except when using ‘guix download’, this code’s stdout is
always captured by the daemon, which in turn passes it to the client
(the ‘guix’ command), and the client’s terminal width can hardly be
known to the download code.

However, commit b0a6a9713076347c14ee2dd0ea494ab086df2a82 improves the
situation in some cases.

> 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).

‘string-length’ returns the number of Unicode codepoints, which is the
number of glyphs in this case.

> 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.

I believe this one is fixed by 8a2154fefaafe631905c12891c9c2587dadbc863.

> 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.

This was initially discussed at
<https://lists.gnu.org/archive/html/guix-devel/2015-09/msg00390.html>.
It seems we’ve diverged from what was proposed there, though.

Thoughts?

> 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.

So, what would be your preference?  :-)

> 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.

No idea.

Thanks for your feedback!

Ludo’.