Re: RFC: git diff colorization idea

Wincent Colaiuta [off-list ref] 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.

El 23/1/2009, a las 1:32, Junio C Hamano escribió:

Wincent Colaiuta [off-list ref] writes:

quoted

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.

Yes, mine too. I wouldn't actually use those colors in practice.  (Doubly so because the "removed" color looks like the "whitespace  error" color.)

I'll whip something up with non-garish defaults.

Cheers,
Wincent

Quoting Junio C Hamano [off-list ref]:

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.

I think this makes a lot more sense than any of the screenshot
WIncent prepared on his web pages, and it is a much easier output
for users to spot which word is different by not coloring the
unchanged word at all.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/