On Tue, Jun 04, 2024 at 08:32:04AM -0700, Junio C Hamano wrote: > The default that colors the output is something we might later > regret. Those who want colored output can always use the > interactive.diffFilter configuration, but I am not sure if going > the other direction to strip coloring is just as easy. But other > than that, I think we are at an OK place to stop. I don't think diffFilter is a great solution there. In my experience, that is augmenting the existing coloring done by "diff --color" itself (and of course many people do not use a separate filter in the first place, and just see the normal color output). So there's not an easy way to add the color back to a stripped version. The interactive-patch code is literally holding the two color/non-color variants in memory, splitting the hunks based on line counts, and then showing you one and applying the other. Even if you wanted to run "git diff --color" yourself in the "|" command, it would be a lot of work to pick out the hunk of interest. Given that the main use case for "|" is for human viewing through a pager, I think the colorful, filtered version meant for users is the best default. And then the "bare" version can come from an alternate command or a knob. Just to note some prior art, mutt's "<pipe-message>" faces a similar problem. You might want the raw message (if you're going to poke at headers, MIME parts, etc yourself) or you may want a decoded one (if you just care about body text and don't want to deal with base64, qp, etc, yourself). They provide a stateful config knob, but then you end up with horrible macros that toggle the knob, like: :set pipe_decode=yes<enter><pipe-message>my-script<enter>:set pipe_decode=no<enter> I think having two separate commands for the two modes would be less confusing. -Peff
