From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: acm@muc.de, emacs-devel@gnu.org, dgutov@yandex.ru
Subject: Re: master 7362554: Widen around c-font-lock-fontify-region. This fixes bug #38049.
Date: Thu, 14 Nov 2019 16:29:38 -0500 [thread overview]
Message-ID: <jwvy2wi5fsx.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83h836466w.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 14 Nov 2019 21:19:03 +0200")
>> I think the problem is wider than CC-mode. Maybe CC-mode is more
>> susceptible to it or maybe it's just an accident that this was reported
>> for CC-mode, but running font-lock (and syntax-propertize) within
>> narrowing tends to be fiddly.
> I'm also okay with fixing it in font-lock or jit-lock. But doing that
> inside reposition.el makes no sense to me.
IIUC this can't be fixed in font-lock or jit-lock. It can only be fixed
"upstream" (e.g. in repos-count-screen-lines) or "downstream" (in the
particular major mode's rules).
I think neither "upstream" nor "downstream" is satisfactory, but
until/unless we introduce some "structure" on the narrowings (so that
font-lock can know for sure whether and how it can widen) that's what we
have to live with.
> So we are going to do such changes in every application that calls
> vertical-motion, directly or indirectly?
I'd phrase it as "this would need to be done in any narrowing
which changes point-min and internally can trigger jit-lock".
Whether we're going to do it or not I don't know.
I think "don't change point-min" is generally the better fix (which
partly means weaning ourselves from narrowing).
> And what about posn-at-point, or pos-visible-in-window-p, or any other
> API that uses the display code internally?
If these can trigger jit-lock then that applies as well, yes.
`sit-for` as well, BTW.
> are we going to fix their callers as well?
The fix should not be "where we can do vertical-motion (and friends)"
but "where we narrow (and later trigger jit-lock)". Whether that means
"fix their callers as well" depends on what it is that owns the "their
callers": yes it would be in the functions that call (directly or not)
`vertical-motion` (and friends) but in the functions that call
those functions.
>> > In particular, what if the POINT-MIN..END chunk is still too large to
>> > fontify in one go?
>> AFAIK all uses of jit-lock are more efficient if they get fewer larger
>> chunks than more smaller chunks.
> So you are saying that we should enlarge jit-lock-chunk-size to
> most-positive-fixnum?
That would cause jit-lock being applied not just to "fewer larger
chunks" but also to more total text: when the redisplay calls jit-lock,
we know POS will be displayed and needs to be jit-locked but we don't
how far further we will keep looking, and that what jit-lock-chunk-size
is for (it's supposed to be large enough that the per-chunk overhead
doesn't kill it while being small enough that the amount of text
we needlessly jit-lock isn't too large either).
In the presently discussed patch we know beforehand that all the text
between start and end will be considered and will need to be jit-locked,
which is why we can do it more efficiently in a single explicit call
than what the redisplay code would do otherwise.
In any case, changing the narrow-to-region so it doesn't change
point-min is the right fix. Adding a call to `jit-lock-fontify-now` is
another but worse way to fix it.
Adding that call should be harmless and could be beneficial for
performance, but I personally wouldn't do it (it can also be harmful
for performance in the case where the text has already been jit-locked
in which case it won't do anything but will still take a bit of time to
do it).
Stfan
next prev parent reply other threads:[~2019-11-14 21:29 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20191109144026.20810.76129@vcs0.savannah.gnu.org>
[not found] ` <20191109144027.DDC3720927@vcs0.savannah.gnu.org>
2019-11-11 16:52 ` master 7362554: Widen around c-font-lock-fontify-region. This fixes bug #38049 Dmitry Gutov
2019-11-11 20:34 ` Alan Mackenzie
2019-11-12 13:36 ` Dmitry Gutov
2019-11-13 21:19 ` Alan Mackenzie
2019-11-13 22:33 ` Dmitry Gutov
2019-11-14 13:42 ` Stefan Monnier
2019-11-14 14:05 ` Dmitry Gutov
2019-11-14 14:29 ` Eli Zaretskii
2019-11-14 14:35 ` Dmitry Gutov
2019-11-14 14:48 ` Eli Zaretskii
2019-11-14 14:50 ` Dmitry Gutov
2019-11-14 16:08 ` Eli Zaretskii
2019-11-14 21:07 ` Dmitry Gutov
2019-11-15 9:31 ` Eli Zaretskii
2019-11-15 10:24 ` Dmitry Gutov
2019-11-15 13:00 ` Eli Zaretskii
2019-11-14 13:49 ` Eli Zaretskii
2019-11-14 14:08 ` Dmitry Gutov
2019-11-14 14:37 ` Dmitry Gutov
2019-11-14 14:55 ` Stefan Monnier
2019-11-14 15:02 ` Dmitry Gutov
2019-11-14 15:33 ` Stefan Monnier
2019-11-14 16:12 ` Eli Zaretskii
2019-11-14 18:51 ` Stefan Monnier
2019-11-14 19:19 ` Eli Zaretskii
2019-11-14 19:48 ` Dmitry Gutov
2019-11-14 19:56 ` Eli Zaretskii
2019-11-14 19:59 ` Dmitry Gutov
2019-11-15 7:34 ` Eli Zaretskii
2019-11-15 7:52 ` Dmitry Gutov
2019-11-14 21:29 ` Stefan Monnier [this message]
2019-11-14 21:46 ` Dmitry Gutov
2019-11-15 9:36 ` Eli Zaretskii
2019-11-15 10:26 ` Dmitry Gutov
2019-11-15 23:27 ` Stefan Monnier
2019-11-16 8:02 ` Eli Zaretskii
2019-11-17 0:50 ` Stefan Monnier
2019-11-17 3:33 ` Eli Zaretskii
2019-11-17 7:36 ` Dmitry Gutov
2019-11-17 15:44 ` Eli Zaretskii
2019-11-17 17:59 ` Dmitry Gutov
2019-11-17 18:26 ` Eli Zaretskii
2019-11-17 18:35 ` Dmitry Gutov
2019-11-14 19:58 ` Dmitry Gutov
2019-11-14 21:24 ` Several Major Modes. [Was: master 7362554: Widen around c-font-lock-fontify-region. This fixes bug #38049.] Alan Mackenzie
2019-11-14 22:11 ` Dmitry Gutov
2019-11-15 20:10 ` Several Major Modes Alan Mackenzie
2019-11-15 21:45 ` Dmitry Gutov
2019-11-16 13:10 ` Alan Mackenzie
2019-11-17 12:48 ` Dmitry Gutov
2019-11-17 16:03 ` Alan Mackenzie
2019-11-17 21:56 ` Dmitry Gutov
2019-11-14 13:35 ` master 7362554: Widen around c-font-lock-fontify-region. This fixes bug #38049 Eli Zaretskii
2019-11-15 22:43 ` Dmitry Gutov
2019-11-14 12:02 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvy2wi5fsx.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=acm@muc.de \
--cc=dgutov@yandex.ru \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.