Wincent Colaiuta <win@xxxxxxxxxxx> writes:
> I'm also thinking that perhaps a per-character approach might be
> useful here instead of a per-word one (it would make that last hunk
> look better in the mock-up screenshot that I posted); if I go the per-
> character route then that suggests that "--color-chars" might be the
> right option name, and the color slots would then be
> color.diff.new.char and color.diff.old.char.
>
> Any feedback or suggestions before I get in too deep?
I personally find your "prposal" picture too loud to my eye.
I would have expected you to propose something like this:
| _git_remote ()
| {
|- local subcommands="add rm show prune <red>update</red>"
|+ local subcommands="add <green>rename</green> rm show prune"
| local subcommand=$(__git_find_subcommand "$subcommands")"
| if ...
if the patch were to remove update and add rename, that is. If there is
no deletion but only insertion, you would only see green.
And that way you do not need new color slots. You can use new color and
old color as before, and the coloring will be done to highlight only the
parts that really matter.
If you were to go this route, I suspect that showing the unchanged part on
the preimage line in light gray might make sense, like:
| _git_remote ()
| {
|- <gray>local subcommands="add rm show prune<gray> <red>update</red>"
|+ local subcommands="add <green>rename</green> rm show prune"
| local subcommand=$(__git_find_subcommand "$subcommands")"
| if ...
because there will be the same chars/words on the postimage line anyway.
Just 2c from somebody who does not like colors very much.
--
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
