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

[Stefan Monnier]

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

I bumped into one a week ago where I killed `diff` after several minutes.

> Is it a matter of using "start-process" instead of "call-process"?

That's the starting point, yes, but it also involves moving the
"subsequent" code to the process's sentinel.

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

Could be, tho maybe you can make it DWIM enough (i.e. turn off if
there's nothing to refresh).

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

Since I find font-lock-maximum-decoration fundamentally flawed, I'm
rather in the business of deprecating it than increasing its use.


        Stefan