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