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
signature.asc
Description: PGP signature
