[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: |
Sat, 13 Oct 2018 15:42:54 +0200 |
> 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.