Re: [PATCH] add--interactive: allow diff colors without interactive colors

Jeff King [off-list ref] 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."
...

quoted

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:
...

quoted

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).