| 1 |
On 14/12/19 12:03, Kent Fredric wrote: |
| 2 |
> On Sat, 14 Dec 2019 08:16:03 +0100 |
| 3 |
> Ulrich Mueller <ulm@g.o> wrote: |
| 4 |
> |
| 5 |
>> These prevent NOCOLOR in make.conf or emerge --color=n from working |
| 6 |
>> correctly, and I guess they are also problematic from an accessibility |
| 7 |
>> point of view. |
| 8 |
>> |
| 9 |
>> Are there any objections against removing these sequences from strings? |
| 10 |
>> AFAICS, they are used by less than ten packages, and one eclass. |
| 11 |
> Maybe we can have some future EAPI feature, or special eclass, that |
| 12 |
> allows people to add escape codes while also respecting the |
| 13 |
> configuration. |
| 14 |
> |
| 15 |
> Sort of like what git has in its formatting codes, where they're turned |
| 16 |
> off when colours are turned off. |
| 17 |
> |
| 18 |
> hl 1 "${@}" # because 'hl' inherently behaves like echo when not captures |
| 19 |
> einfo "Fetching $(hl "${r}" ) ..." |
| 20 |
> |
| 21 |
> Or something along those lines? |
| 22 |
> |
| 23 |
> I'd wager that a large body of things "not using it" is not because |
| 24 |
> it wouldn't be useful, but due to people knowing this problem exists? |
| 25 |
> |
| 26 |
> -- Further Bikeshed -- |
| 27 |
> |
| 28 |
> Maybe it could even be thematic? |
| 29 |
> |
| 30 |
> "Fetching $(hl url https://path.to/whatever )" |
| 31 |
> |
| 32 |
> Nah. |
| 33 |
> |
| 34 |
> But < hl <colour-code-string> <string> > as a general concept works. |
| 35 |
> |
| 36 |
Something that could be included in gentoo-functions script(s)? |
Archives