On Tue, Oct 17, 2017 at 10:13:34AM +0900, Junio C Hamano wrote: > Jeff King <p...@peff.net> writes: > > > Alternatively, I suppose we could just always escape in > > add--interactive. I'm trying to think of a case where somebody would > > really want their diffFilter to see the raw bytes (or vice versa, to > > show raw bytes produced by their filter), but I'm having trouble coming > > up with one. > > Your patch below only implements the "tame the raw bytes that come > out of their filter", which is quite agreeable.
Yes. I think that is probably OK, especially given that we continue to allow terminal escapes (certainly some filters would want to use colors; I don't know if any would want to use more exotic control codes). > > I can't help but feel this is the tip of a larger iceberg, though. E.g., > > what about characters outside of the terminal's correct encoding? Or > > broken UTF-8 characters? > > Hmph. If you use it as a "built-in" that is a fallback for > diffFilter, i.e. use it only when the end user does not have one, > then users can override whatever wrong thing the built-in logic does > so... ;-) Yes, and maybe that is the best way to do it. It just seems like it is opening a can of worms about exactly which things should be filtered and how. I also wondered if people would be annoyed that by using a filter, they don't get the benefit of the escaping, unless their filter implements it separately on top (and the original purpose of the filter option was for things like diff-highlight and diff-so-fancy, which do not do such escaping). -Peff
