1 |
On Sat, 14 Dec 2019 08:16:03 +0100 |
2 |
Ulrich Mueller <ulm@g.o> wrote: |
3 |
|
4 |
> These prevent NOCOLOR in make.conf or emerge --color=n from working |
5 |
> correctly, and I guess they are also problematic from an accessibility |
6 |
> point of view. |
7 |
> |
8 |
> Are there any objections against removing these sequences from strings? |
9 |
> AFAICS, they are used by less than ten packages, and one eclass. |
10 |
|
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. |