Pádraig Brady wrote:
Matthew Woehlke wrote:
Pádraig Brady wrote:
Hmm, it's worth adding a test at least to demonstrate that
file permissions take precedence over hardlink coloring
I.E. multi hardlinked png and exectuable files will be colored
inconsistently.
If I can interject a question here... I hope I will remember to turn
this back on when that becomes necessary, as I happen to think it is
useful. I am wondering, however, is it, or will it be possible to use MH
to assign a background color, and have the foreground color come from
whatever else would set one? It seems this would be the most useful.
I agree it would be useful to do but we don't support that
unfortunately and can't really as existing user colour settings
could be setting backgrounds.
If they set backgrounds, that should cancel any background set by MH. I
didn't mean it that way. What I am wondering is if other settings
/don't/ set a background, but MH does... will the MH setting be parsed
first, or ignored completely?
I am thinking something like this (for e.g. .jpg with multiple links):
MH says bg=4, fg=6
.jpg says fg=8
...so what happens is:
(defaults) bg=(empty), fg=(\e[0m)
do we have multiple links? yes -> bg=4, fg=6
are we .jpg? yes -> fg=8
result: bg=4, fg=8
...but I guess that would only stack by emitting the full string for
both, i.e.:
\e[36;44m\e[38mfile.jpg
Nevertheless... would this be a worthwhile idea?
This makes me think of something else, is 'ls' able to use 256- and
24-bit-color escape sequences?
Yep, it will just replace what ever strings are present:
Okay, that's what I thought. Thanks.
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Never give up on learning
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
