On 11/15/2011 04:27 AM, Alex Alexander wrote: > On Mon, Nov 14, 2011 at 07:19:35AM -0800, Zac Medico wrote: >> On 11/14/2011 12:25 AM, Alex Alexander wrote: >>> On Sun, Nov 13, 2011 at 05:59:21PM -0800, Zac Medico wrote: >>>> Well, it's much easier to gather interest and get feedback if we deploy >>>> the change and ask questions later. >>> >>> What if we tried solving this problem by providing more options instead >>> of trying to guess what the users want? :) >>> >>> Imagine the following output (when jobs == 1): >>> >>>>>> Verifying ebuild manifests >>>>>> Emerging (1 of 1) www-client/chromium-16.0.912.36 >>>>>> Quiet building enabled. Enable for [P]ackage or [S]ession. [L]earn more. >>>>>> Jobs: 0 of 1 complete, 1 running Load avg: 0.23, 0.18, >>>>>> 0.10 >>> >>> Pressing P would only show the log for the actively built package. >>> Pressing S would show all the logs for this session, starting with the >>> active one. >>> >>> Pressing L would print out a short set of instructions, something >>> like: >>> >>> "To make portage output easier to track and understand, --quiet-build >>> has been enabled by default. You may restore the old, verbose behavior >>> temporarily by using the P and S commands, or permanently by adding >>> '--quiet-build=n' to your make.conf's EMERGE_DEFAULT_OPTS." >>> >>> I believe many users would appreciate the ability to output logs on >>> demand. :) >> >> I think that would be an interesting option. We could put stdin in raw >> mode, like dispatch-conf does, in order to read single characters of >> input instead of whole lines. >> >> I can imagine that this option wouldn't be desired by some people, if >> only because emerge would consume all keystrokes from the input buffer. >> In the past we had a few portage releases that consumed keystrokes like >> that (it was part of the support for interactive ebuilds), and I recall >> someone (I think it was grobian) complaining because he had a habit of >> typing his next shell command before emerge had completed. > > As long as everything is optional, I don't think we'll have any > reasonable complaints. > > The stdin raw mode would only be enabled when --quiet-build=y and > --jobs=1. Any other combination would switch to standard mode and we > could also introduce an --allow-options=[y/n] (or similar) parameter for > those who want to completely disable the feature. > > I'm confident many users that are currently against quiet-build would > consider it if they were provided with these options :)
I don't know, some people are hard to please. :) > Would it be difficult to implement? It doesn't seem very difficult. We should be able to use the poll loop to handle the input, so it won't require a separate thread. I wouldn't be opposed to adding support for something like this. Since I'm not really interested in using an interface like that myself, so I don't feel inspired to implement it myself. -- Thanks, Zac
