Re: Recent diff-mode changes feel slow with TRAMP

[Juri Linkov <juri@linkov.net>]

> OK. Yes. Setting diff-font-lock-syntax to nil makes it fast again.
> Thanks a lot for pointing me to that.
>
> The docs for diff-font-lock-syntax say that 'hunk-only is the fastest
> setting here, but that's not true, right? Isn't nil the fastest one?

`hunk-only' is the fastest non-nil option.

> For my use cases, I don't think I want this enabled at all, TRAMP or
> not. Combined with refinement, this makes the diffs more difficult to
> interpret, at least to me. And even without TRAMP, this makes it slower.
> Do we really want both refinement and this font-locking enabled by
> default?

Modern version control systems like GitHub and GitLab enable both by default.

> There's also a visual issue with auto-refinement. If I load a patch file
> with 'emacs -Q -rv' (no user settings, but reverse video), it looks like
> this:
>
>   http://notes.secretsauce.net/emacsdiff.png
>
> Note that the bright green refined face makes the leading + invisible.
> There's an identical problem with the bright red making the leading -
> invisible.

It's easy to improve auto-refinement to not put highlighting on diff
indicators like it's already implemented in line-based diff-font-lock-syntax.

BTW, there is another issue that could be improved in auto-refinement:
when changes are only in whitespace it highlights nothing because it's
word-based.  I think in this case it could fall back to the default mode
that doesn't ignore differences in whitespace, thus highlighting whitespace.