bug#32991: 27.0.50; diff-auto-refine-mode a no-op

[charles@aurox.ch (Charles A. Roelli)]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 10 Oct 2018 15:21:27 -0400
> 
> I don't see what the navigation-triggered refinement has of
> "auto"matism, compared to font-lock, so I wouldn't use `auto` here.
> I'd rather go with something like `nil`, `font-lock`, or `navigation`
> (and default to `font-lock`).

Sounds good.

> > While we're on this point, what is the use case for offering automatic
> > refining during navigation if we can now offer "just-in-time"
> > highlighting via font-lock?
> 
> Good question.  Maybe it's just not worth it and we should simply get
> rid of the old navigation-triggered refinement.  This said, the new
> font-lock thingy can be problematic if the diff takes too much time
> since it happens within jit-lock with inhibit-quit set to a non-nil
> value, so it completely freezes your Emacs session, whereas if it
> happens during `n` you can stop it with C-g.
> 
> Hopefully, we can fix this problem by calling `diff` asynchronously so
> it can't block Emacs.

I was able to produce such a case where Emacs froze for 30 seconds on
opening a 2000-line (junk) diff containing one large hunk.

It would indeed be convenient to have "diff" called asynchronously
(assuming this is the "diff" that runs in smerge-refine-regions).  Is
it a matter of using "start-process" instead of "call-process"?

> > It could be even better if C-c C-b could interactively toggle the
> > refining of the hunk at point (for those times when the refining turns
> > out to be an eye-sore).
> 
> Sounds good (but note that diff-refine-hunk can also be useful to
> *refresh* the fine highlighting, e.g. after manually editing a hunk).

Ok, then switching off the refining might fit better on a prefix
argument, or in a new command.

> font-lock-maximum-decoration is fundamentally flawed in that it is
> unidimensional (you can only have more or less) whereas often some users
> may want more of one kind of info and less of another.
> 
> E.g. how would you order the "decoration levels" between:
> 
>     basic
>     basic + refine
>     basic + prettify
>     basic + prettify + refine
> 
> The first and last are easy, but there's no natural ordering between the
> middle two.

Good point.  Maybe we could start with an ordering of just
"basic"/"basic + refine", since the diff-font-lock-prettify option is
brand new and seems to be more about hiding text than decorating it,
IIUC.