From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: bug#22536: guix lint Date: Fri, 15 Apr 2016 00:38:15 +0200 Message-ID: <87shynhl48.fsf@gnu.org> References: <20160407143744.3b0d8e98@scratchpost.org> <20160407150957.GA18750@jasmine> <8760vt84zg.fsf@gnu.org> <20160408200745.49b3a761@scratchpost.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54025) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqpu6-0003gR-C6 for guix-devel@gnu.org; Thu, 14 Apr 2016 18:38:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqpu5-0003D9-8W for guix-devel@gnu.org; Thu, 14 Apr 2016 18:38:26 -0400 In-Reply-To: <20160408200745.49b3a761@scratchpost.org> (Danny Milosavljevic's message of "Fri, 8 Apr 2016 20:07:45 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Danny Milosavljevic Cc: Guix-devel , 22536@debbugs.gnu.org Danny Milosavljevic 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 aga= inst; *: against it with OK mitigation; X: definitely against it): > o The terminal width is not passed to it correctly (can be fixed, althoug= h 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 sc= ripts/download so it reprints the progress text). Now you can have a race b= etween (1) and (2), fun. > * The terminal width can be changed after the script is done and has prin= ted 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 =E2=80=98guix download=E2=80=99, this code= =E2=80=99s stdout is always captured by the daemon, which in turn passes it to the client (the =E2=80=98guix=E2=80=99 command), and the client=E2=80=99s terminal wid= th 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 w= ould 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 v= ariable-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). =E2=80=98string-length=E2=80=99 returns the number of Unicode codepoints, w= hich is the number of glyphs in this case. > I can also fix up string-pad-middle while maintaining its way, but just f= or the record, this is a bad way of doing it. > > If we are concerned about all emphemeral "transferred" lines lining up, j= ust print the speed first (with fixed width, if possible) and the URL after= wards, 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 . It seems we=E2=80=99ve diverged from what was proposed there, though. Thoughts? > If we do print a table, I would suggest setting a tab stop (using ESC H o= r similar) and using the tab character to print tables - that's what they a= re for. Note: there's a standalone "column -t" tool which also does the rig= ht 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 ent= ire paragraph - so it does know what extent the paragraph has. However, pri= nting CR returns me to the beginning of the row, not the beginning of the p= aragraph. No idea. Thanks for your feedback! Ludo=E2=80=99.