Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Ionen Wolkens]

On Sat, Oct 02, 2021 at 06:04:36PM -0400, Ionen Wolkens wrote:
> On Sat, Oct 02, 2021 at 09:22:49AM +0200, Ulrich Mueller wrote:
> > >>>>> On Wed, 29 Sep 2021, A Schenck wrote:
> >
> > > On 9/28/21 8:36 AM, Michał Górny wrote:
> > >> [WW] some message
> > >> [EE] other message
> > >> [QA] hell if i know what this is
> > >>
> > >> I've also added more colors to explicitly distinguish einfo from elog,
> > >> and ewarn from eqawarn.  Then, I've replaced most of '>>>' and '!!!'
> > >> used by Portage with four-character versions to keep messages aligned.
> > >> The 'zings' used for merging files remain three-character, so now it's
> > >> easily possible to distinguish messages from installed file list.
> >
> > > Didn't expect to be the only dissenting opinion on something like this
> > > but. . . Some applications parse portage output looking for these
> > > 'zings'. At very least app-portage/kuroo does it this way; there must be
> > > others, right? This is obviously not the ideal way to get information
> > > out of portage, but it's been stable for the 15 years Kuroo has existed.
> > > 10-ish years ago dol-sen started some work on building and API for
> > > portage, but then got sucked into core portage development to the point
> > > of abandoning their GTK+ portage GUI porthole, which was the original
> > > impetus for an API, and as far as we know, the API never made it to the
> > > point it could replace parsing the output.
> >
> > If only the length of the >>> and !!! strings is a problem, then why not
> > leave them alone and go for single-letter tags instead? Like this:
> >
> >    [.] einfo
> >    [I] elog
> >    [W] ewarn
> >    [E] eerror
> >    [Q] eqawarn
> >
> > The only problematic one is [Q] instead of [QA] which is no longer
> > self-explanatory. Then again, only devs and experienced users should see
> > eqawarn messages.
>
> fwiw eqawarn is currently displayed for everyone in a similar manner
> as einfo, just not post-emerge/elog without adding to ELOG classes.
>
> If users aren't hiding build logs entirely, they may notice those
> done at the end (often shown after size report) -- and possibly
> think it's a problem.
>
> Not to say whether [Q] vs [QA] would help with this much so I have
> no strong opinion here.

Guess there's a lot of other options that could be considered as well.

--- files
>>> text
 * current, it wasn't aligned now that I look at it again
(relying only on color to convey type feels clearly wrong to me)

--- files
>>>> text
[QA] new based on current PR

>>> text
[QA] aligned 1 character further, maybe skipping changing >>> is fine?
(then again that it's further is what threw me off at first)

>>> text
QA* similar to before, but aligned using only 3 chars

>>> text
[Q] kinda more obscure but it can work

>>>> text
QA* probably closest to how it was before alignment-wise, but meh at 4 >

>>> message
QA> not convinced about this one, but throwing it here anyway
(other characters could be considered as well)

Maybe a poll of some kind may help, personally undecided on what I
like better beside agreeing that a change is needed.

-- 
ionen