[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Charles A. Roelli
Subject: bug#32991: 27.0.50; diff-auto-refine-mode a no-op
Date: Wed, 10 Oct 2018 20:31:52 +0200

> From: Stefan Monnier <address@hidden>
> Date: Tue, 09 Oct 2018 15:54:55 -0400
> >> >>     * lisp/vc/diff-mode.el: Perform hunk refinement from font-lock
> >> > Looks like this commit makes diff-auto-refine-mode a no-op, since
> >> > hunks are now always refined.  Is that the intention?
> >> Yes.  Of course, it depends on the value of diff-font-lock-refine.
> > Ok.  In that case, do we still need diff-auto-refine-mode?
> It should probably be merged with diff-font-lock-refine (e.g. have
> 3 possible values).

So diff-font-lock-refine could have 3 possible values, t and nil as it
has now, and 'auto for doing the refinement as you navigate to hunks
with "n" or "p".

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?  The new, instant refining seems more
logical and less surprising to the user.  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).

Another advantage of the new font-lock based approach is that with a
little change we might be able to customize how much highlighting is
done in a diff-mode buffer via "font-lock-maximum-decoration".

reply via email to

[Prev in Thread] Current Thread [Next in Thread]