Jeff King <peff@xxxxxxxx> writes:
> But he doesn't have to care about that. He cares only that "color.diff"
> means "diffs are displayed in color." And "color.interactive" means
> "interactive menus are displayed in color."
> ...
>> If he told "git add -p" to be monochrome, he has every right to expect
>> the part to pick hunks to also stay monochrome. To people who know
>
> But he didn't. He said "git menus should be monochrome."
Who said anything about "interactive is limited to interactive
menus" anywhere? That is where we differ and what you do not
seem to be getting. I am talking about color.interactive that
controls the whole user experience of interacting with "add -i".
> Moreover, this doesn't allow "I always want color in diffs,
> but I don't want menu coloring" which is the very thing I have
> been trying to accomplish (but yes, I can do that by
> individually setting color.interactive.* to plain).
As you said earlier you may also be minority, but yes the color
pallette would help you do that.
> I fail to see how this is less confusing than just adding a separate
> interactive-diff knob, since you are asking them to individually set
> each color preference to plain.
What I am aiming at in longer term is to simplify things this way:
* Users are categorized broadly into two groups. The ones who
like colours and the ones who don't want colours at all.
color.git would control this (with backward compatibility
options per command such as color.diff and
color.interactive);
* Minorities who want to disable colours for particular parts
of the UI have enough knobs to tweak in the form of palettes.
By definition this needs to address "particular parts", so
"color.$command.$context" variables (e.g. color.diff.new,
color.interactive.new; if somebody really really wants to
have different settings between diff/show/log, that person
could add color.{show,log}.new as well) are needed if we want
to do this.
> E.g., given
> config options:
> ...
>> Admittedly, it's more work.
>
> Of course. ;) But I am willing to implement what I said above if you
> agree that it is sensible.
I think we share the ultimate goal of introducing higher level
knobs and our difference is just about minor details of how to
get there and what the intermediate levels look like.
I am trying to avoid introducing new intermediate level knobs
(e.g. color.log vs color.diff), as it is enough to disable or in
general change the way particular parts of the UI is coloured by
palette setting that specifically states which part of the UI is
tweaked (e.g. color.interactive.prompt).
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
