Re: Consider escaping special characters like 'less' does

From: Jeff King <peff@peff.net>
Date: Oct 17, 2017, 02:45 UTC
Message-ID: <20171017024540.erccnanmvz6t2aue@sigill.intra.peff.net>
In-Reply-To: <xmqqk1zur2yp.fsf@gitster.mtv.corp.google.com>

On Tue, Oct 17, 2017 at 10:13:34AM +0900, Junio C Hamano wrote:

Show 10 quoted lines

> Jeff King <peff@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).

Show 8 quoted lines

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