[thg-dev] [RFC] colors... colors!

[Sune Foldager]

Moving on with my stream of RFCs, today it's COLORS!

We inherit the colors from hgrc, such as color.status.added, but this is
not a good idea since users will generally set these with the underlying
expectation that they are shown against a black background.

The default colors happen to look ok on both black and white, except for
status.deleted which is then hard-coded to a different color in
changeset 1d113569d4b6 by Steve. This, however, does no work if it's
overridden in the config.

I propose we introduce new keywords, thgstatus.* or whatever, and set
the default colors as we like them (probably like the defaults for
status.* plus the change in the mentioned changeset), and then accept
that changes to status.* aren't propagated; this will more often than
not be a good thing.

Thoughts?

/Sune

[Steve Borho]

Post by Sune Foldager
Moving on with my stream of RFCs, today it's COLORS!
We inherit the colors from hgrc, such as color.status.added, but this is
not a good idea since users will generally set these with the underlying
expectation that they are shown against a black background.
The default colors happen to look ok on both black and white, except for
status.deleted which is then hard-coded to a different color in
changeset 1d113569d4b6 by Steve. This, however, does no work if it's
overridden in the config.
I propose we introduce new keywords, thgstatus.* or whatever, and set
the default colors as we like them (probably like the defaults for
status.* plus the change in the mentioned changeset), and then accept
that changes to status.* aren't propagated; this will more often than
not be a good thing.

See tortoisehg/hgqt/qtlib.py 214. We do allow thg specific colors to
override the base configuration.

[Sune Foldager]

Post by Steve Borho

Post by Sune Foldager
Moving on with my stream of RFCs, today it's COLORS!
We inherit the colors from hgrc, such as color.status.added, but this is
not a good idea since users will generally set these with the underlying
expectation that they are shown against a black background.
The default colors happen to look ok on both black and white, except for
status.deleted which is then hard-coded to a different color in
changeset 1d113569d4b6 by Steve. This, however, does no work if it's
overridden in the config.
I propose we introduce new keywords, thgstatus.* or whatever, and set
the default colors as we like them (probably like the defaults for
status.* plus the change in the mentioned changeset), and then accept
that changes to status.* aren't propagated; this will more often than
not be a good thing.

See tortoisehg/hgqt/qtlib.py 214. We do allow thg specific colors to
override the base configuration.

No, because when my .hgrc has color.status.modified = yellow bold,
because I like it displayed against the bluish background in PowerShell
on Windows, TortoiseHg uses the same color for modified files,
displaying it against a white background where it's illegible.

The changeset I mentioned above solves this for the particular default
setting of status.modified (by changing the default value), but doesn't
address the situation where the default colors have been changed by user
hgrc's; and, for instance, with standard PowerShell palette (which
sucks), some of these defaults have to be changed in order to be able to
actually read the status output.

Since the background color is different in Mercurial (generally assumed
to be black) and TortoiseHg (white), using the same setting for both
seems wrong.

The line you pointed to above doesn't seem to define any colors that
lets me override the use of status.modified etc. It's not the same as
log.modified; I'm talking about status (as in the commit window), not log.

-Sune

[Steve Borho]

Post by Sune Foldager
Moving on with my stream of RFCs, today it's COLORS!
We inherit the colors from hgrc, such as color.status.added, but this is
not a good idea since users will generally set these with the underlying
expectation that they are shown against a black background.
The default colors happen to look ok on both black and white, except for
status.deleted which is then hard-coded to a different color in
changeset 1d113569d4b6 by Steve. This, however, does no work if it's
overridden in the config.
I propose we introduce new keywords, thgstatus.* or whatever, and set
the default colors as we like them (probably like the defaults for
status.* plus the change in the mentioned changeset), and then accept
that changes to status.* aren't propagated; this will more often than
not be a good thing.

See tortoisehg/hgqt/qtlib.py 214.  We do allow thg specific colors to
override the base configuration.

No, because when my .hgrc has color.status.modified = yellow bold, because I
like it displayed against the bluish background in PowerShell on Windows,
TortoiseHg uses the same color for modified files, displaying it against a
white background where it's illegible.
The changeset I mentioned above solves this for the particular default
setting of status.modified (by changing the default value), but doesn't
address the situation where the default colors have been changed by user
hgrc's; and, for instance, with standard PowerShell palette (which sucks),
some of these defaults have to be changed in order to be able to actually
read the status output.
Since the background color is different in Mercurial (generally assumed to
be black) and TortoiseHg (white), using the same setting for both seems
wrong.
The line you pointed to above doesn't seem to define any colors that lets me
override the use of status.modified etc. It's not the same as log.modified;
I'm talking about status (as in the commit window), not log.

So you would add:

[thg-colors]
status.modified = GUI-COLOR

and those would override any configuration you had for

[color]
status.modified = CLI-COLOR

What am I missing?

[Sune Foldager]

Post by Steve Borho

[...]
The line you pointed to above doesn't seem to define any colors that lets me
override the use of status.modified etc. It's not the same as log.modified;
I'm talking about status (as in the commit window), not log.

[thg-colors]
status.modified = GUI-COLOR
and those would override any configuration you had for
[color]
status.modified = CLI-COLOR
What am I missing?

Ah, that makes more sense, thanks. I assumed the overrides in the code
were added to the existing color section, implicitly.

I still think thg-color shouldn't inherit from color, since it in
general doesn't make sense. Wouldn't it be better to just fix thg-color
internally to be identical to the default color (except for the change
done in the cset mentioned)? Again, people use color for
white-on-black, and thg displays black-on-white.

TL;DR: color and thg-color have different domains, IMO, and doing
inheritance between them will probably almost always give the wrong result.

/Sune

[Steve Borho]

Post by Steve Borho

[...]
The line you pointed to above doesn't seem to define any colors that lets me
override the use of status.modified etc. It's not the same as log.modified;
I'm talking about status (as in the commit window), not log.

[thg-colors]
status.modified = GUI-COLOR
and those would override any configuration you had for
[color]
status.modified = CLI-COLOR
What am I missing?

Ah, that makes more sense, thanks. I assumed the overrides in the code were
added to the existing color section, implicitly.
I still think thg-color shouldn't inherit from color, since it in general
doesn't make sense. Wouldn't it be better to just fix thg-color internally
to be identical to the default color (except for the change done in the cset
mentioned)?  Again, people use color for white-on-black, and thg displays
black-on-white.
TL;DR: color and thg-color have different domains, IMO, and doing
inheritance between them will probably almost always give the wrong result.

I dunno, red is red so long as they're not mucking with the background
colors. I see your point but it would break backward compatibility
for something that can be resolved with a bit more verbiage in your
INI file. So I'm at a +0.45