Hide progress bar if input is stdin only#1938
Conversation
|
Personally, I'm okay with the current behaviour. As mentioned in #1914 (comment) and #1736 (comment) I find it unexpected to fully hide the bar if stdin is one of the inputs. The main reason is that this might confuse users a lot. I assume the more common use case is to pipe something to lychee, rather than plain |
Oh, I hadn't thought of that. Nice catch! Yeah, it's a bit of a tradeoff. In your recording (now archived), I got a bit irritated by the progress bar. It looked like a rendering bug, to be honest. But as you pointed out, there's no easy solution here. 😕 Or so I thought! Maybe we should only hide the progress bar when stdin is not a TTY (i.e., it's being piped or redirected). If someone runs I tweaked the behavior a bit. The implementation now detects when stdin is piped or redirected and hides the progress bar only in those cases. What do you think? 🤩 |
|
Ooh I didn't know this was possible 👍 It still feels a bit like a hack but I'm okay with it, if we are even more strict with the predicate and set |
|
Quick heads-up: When I tested this, I think I found a few issues. That means, we should test that thoroughly before merging. Don't have time to re-run the tests right now, but if someone wants to check out this branch and try it on a few inputs, that would be helpful. |
In #1914, work was done to hide the progress bar on `stdin`. The simple solution of removing enable_steady_tick for the progress bar. This worked well for avoiding cluttering the output while the user typed their input. However, the initial progress bar still gets shown, which is not ideal. This commit slightly imporves the behavior by waiting for all inputs before showing the progress bar. We do this by iterating over the inputs and checking if any of them is `stdin`. This way, the progress bar does no longer get shown. To start the processing, the user has to press Ctrl^D, which is customs for other Unix tools as well. Other behavior remains unchanged.
a3d4b01 to
0e128a9
Compare
|
I took another look and decided to avoid hiding the progress bar if there are more inputs than just lychee - README.mdIt would show the progress bar. @thomas-zahner, wdyt? |
aa38bd2 to
67df0fa
Compare
67df0fa to
38c1889
Compare
thomas-zahner
left a comment
There was a problem hiding this comment.
Cool, that's a lovely little improvement 🚀
stdinstdin only
In #1914, work was done to hide the progress bar on
stdin. The simple solution of removing enable_steady_tick for the progress bar. This worked well for avoiding cluttering the output while the user typed their input.However, the initial progress bar still gets shown, which is not ideal. This commit slightly imporves the behavior by waiting for all inputs before showing the progress bar. We do this by iterating over the inputs and checking if any of them is
stdin.This way, the progress bar does no longer get shown. To start the processing, the user has to press Ctrl^D, which is customs for other Unix tools as well. Other behavior remains unchanged.