| 1 |
>>>>> On Wed, 29 Sep 2021, A Schenck wrote: |
| 2 |
|
| 3 |
> On 9/28/21 8:36 AM, Michał Górny wrote: |
| 4 |
>> [WW] some message |
| 5 |
>> [EE] other message |
| 6 |
>> [QA] hell if i know what this is |
| 7 |
>> |
| 8 |
>> I've also added more colors to explicitly distinguish einfo from elog, |
| 9 |
>> and ewarn from eqawarn. Then, I've replaced most of '>>>' and '!!!' |
| 10 |
>> used by Portage with four-character versions to keep messages aligned. |
| 11 |
>> The 'zings' used for merging files remain three-character, so now it's |
| 12 |
>> easily possible to distinguish messages from installed file list. |
| 13 |
|
| 14 |
> Didn't expect to be the only dissenting opinion on something like this |
| 15 |
> but. . . Some applications parse portage output looking for these |
| 16 |
> 'zings'. At very least app-portage/kuroo does it this way; there must be |
| 17 |
> others, right? This is obviously not the ideal way to get information |
| 18 |
> out of portage, but it's been stable for the 15 years Kuroo has existed. |
| 19 |
> 10-ish years ago dol-sen started some work on building and API for |
| 20 |
> portage, but then got sucked into core portage development to the point |
| 21 |
> of abandoning their GTK+ portage GUI porthole, which was the original |
| 22 |
> impetus for an API, and as far as we know, the API never made it to the |
| 23 |
> point it could replace parsing the output. |
| 24 |
|
| 25 |
If only the length of the >>> and !!! strings is a problem, then why not |
| 26 |
leave them alone and go for single-letter tags instead? Like this: |
| 27 |
|
| 28 |
[.] einfo |
| 29 |
[I] elog |
| 30 |
[W] ewarn |
| 31 |
[E] eerror |
| 32 |
[Q] eqawarn |
| 33 |
|
| 34 |
The only problematic one is [Q] instead of [QA] which is no longer |
| 35 |
self-explanatory. Then again, only devs and experienced users should see |
| 36 |
eqawarn messages. |
| 37 |
|
| 38 |
Ulrich |
Archives