[pacman-dev] Broken pacman output when resizing

[i7c at posteo.de]

Firstly, I agree with Florian's points, i.e. limit to 80 rather than fix
to 80 cols, such that the output does not break if the terminal is
smaller than 80 columns and removing the additinoal whitespace.

Quoting Allan McRae (2015-11-29 14:04:16)
> Pacman's output only goes weird if the terminal width is made smaller,
> and even then only sometimes.  My guess is there is a race condition
> between the time the width is calculated and when the output is printed.
>  If the terminal is shrunk in that time, the output goes over two lines
> and on the next update only the second line is overridden.
> 
> How do you intend to stop this?  While your example looks fine, you will
> still get partial progress bars everywhere in the output when the
> terminal shrinks.

So I think there are really two issues at hand here. One is the "old"
progress bars which are all full at 100% and in the lines above the one
that is currently updated by pacman. Those are never redrawn and they
become ugly (producing linebreaks) when the terminal width is reduced.
My proposal was to remove those, as they provide zero information to the
user. This should be a small patch.

The other thing is the currently drawn/updated progress bar which is
resized and realigned by pacman if the terminal width changes _while_
the progress bar still changes.

Now in this matter I have — honestly — not much experience. I'm just
going to try to explain my point of understanding: If we limit the width
of the whole line to 80 columns (including some status info and the bar)
and we assume that the user never downsizes the terminal below 80
columns, does that potential race condition even matter?  pacman would
only really care for the actual terminal width, if it was below 80,
otherwise it would just draw 80 columns tops and hence procude clean
output in any terminal size. I'm not quite sure, but if this race
condition exists it might be quite difficult (or impossible) to deal
with it in a clean way. Assuming that all terminals are usually >80 cols
could be an okay trade-off.

> 
> Also, we need to consider parallel downloads (this will happen in the
> future).

Very well. I assume the number of parallel jobs is arbitrary but not too
big, so my recommendation is, for 4 parallel downloads:

 jdk8-openjdk-8.u66-1-x86_64
 gtk-update-icon-cache-3.18.5-1-x86_64
 gtk3-3.18.5-1-x86_64
 kded-5.16.0-1-x86_64
 kdesu-5.16.0-1-x86_64
 kjsembed-5.16.0-1-x86_64
 knotifyconfig-5.16.0-1-x86_64
 kpeople-5.16.0-1-x86_64
 kross-5.16.0-1-x86_64
 plasma-framework-5.16.0-1-x86_64
 threadweaver-5.16.0-1-x86_64
 krunner-5.16.0-1-x86_64
 kxmlrpcclient-5.16.0-1-x86_64
 openal-1.17.0-1-x86_64                              [#######-------------]  26%
 oxygen-icons-1:5.16.0-1-any                         [#-------------------]  01%
 texlive-bin-2015.37497-5-x86_64                     [###################-]  94%
 texlive-core-2015.38835-1-any                       [###-----------------]  16%


where the bottom four lines are updated by pacman while the lines above
never change further. If the texlive-bin is done before any of the
above, it is appended to the end of the completed list and this line is
not updated again subsequently. Again, we can argue about the whitespace
after the package name, although I really think it looks nicer when
aligned in this case.
(I left out speed and ETA for the sake of my laziness. I hope you can
imagine those.)

--
Constantin