Re: What is the purpose of fillUpToTermSize?

From: Sergey Matveev <stargrave_at_domain.hidden>
Date: Thu, 29 Apr 2021 14:39:56 +0300
Message-ID: <YIqbDC1FQ4PZVmng_at_domain.hidden>
Greetings!

*** Rin Takanashi [2021-04-29 01:49]:
>I was wondering what is the fillUpToTermSize function supposed to do. From
>the name it seems to stretch the string with spaces to the terminal's width
>but from what I understand it stretches the supplied string to the length
>of the longest previously supplied string.

Initially it was really the function that filled line with spaces up to
terminal's width. But when window gets resized, all that spaces made
awful picture. Later its implementation was replaced with remembering
the previous line length, that did not produce that many invisible
(until window is resized) spaces.

All of that exists only because of statusline that is printed by default
at the bottom of the screen. Very often the text you want to output is
shorter than previously printed status line and you will see part of
statusline after your text. Like in that example:

    $ printf "longstatusline\rmy text\n"
    my texttusline

And I cleared that remaining text with spaces. But you example with seq
200 is good example when that algorithm clearly sucks.

I replaced it with honest CSI ANSI escape sequence that clears the line
to the end. As I understand, it should not harm anywhere. If someone
does not want to see any kind of escape codes, then anyway he will
disable statusline display (-no-status) -- so clearing escape sequence
won't appear at all anywhere. NO_COLOR will disable even printing the
colouring codes too, making goredo's output readable even when captured
with "script" utility for example. And that removes any problems when
window is resized.

I released 1.4.0 version with that change.
Thanks for pointing at that issue! Hope current honest escape code
clearing won't bring any problems I currently do not see.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Received on 2021-04-29 11:39:56 UTC

This archive was generated by hypermail 2.4.0 : 2021-04-29 12:00:08 UTC