From: Dmitry Gutov <dgutov@yandex.ru>
To: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: Re: master 7362554: Widen around c-font-lock-fontify-region. This fixes bug #38049.
Date: Thu, 14 Nov 2019 00:33:33 +0200 [thread overview]
Message-ID: <6fc930a1-eb47-9e54-8752-8cf7ff041586@yandex.ru> (raw)
In-Reply-To: <20191113211936.GB4942@ACM>
Hi Alan,
On 13.11.2019 23:19, Alan Mackenzie wrote:
>> Did that really happen in the reported scenario? I mean,
>> font-lock-dont-widen is usually nil, so font-lock will call widen for
>> you already.
>
> Cutting and pasting from the bug thread for bug #38049:
>
> [ Juri Linkov ]:
> > This is a reproducible test case:
>
> > 0. emacs -Q
> > 1. C-x C-f emacs/lib-src/emacsclient.c
> > 2. M-: (progn (search-forward "create-frame" nil t)
> > (reposition-window))
>
> > Then half screen displays unfontified lines.
>
> > Fontification doesn't fail in other modes, only in C mode.
>
> > This has something to do with interaction between c-font-lock
> > and buffer navigation in reposition-window.
>
> [ Alan Mackenzie ]:
> Indeed it does.
>
> Briefly,
> (i) reposition-window narrows to (2758 3940) in
> repos-count-screen-lines.
> (ii) This latter function uses vertical-motion to count the lines.
> (iii) vertical-motion triggers jit-lock fontification.
> (iv) This calls (eventually) c-font-lock-fontify-region.
> (v) c-font-lock-fontify-region attempts to examine buffer text before
> the start of the jit-lock chunk to find syntactic context.
> (vi) This is outside the visible region, so Emacs raises an exception.
> (vii) The exception is caught and discarded by an unwind-protect in
> c-font-lock-fontify-region.
> (viii) The jit-lock chunk remains unfontified.
Very interesting, thank you. I wonder if the patch below would fix it as
well. Though, if course, that can't account for all possible uses of
vertical-motion inside a narrowed buffer.
diff --git a/lisp/reposition.el b/lisp/reposition.el
index 22f9986efb..131e595858 100644
--- a/lisp/reposition.el
+++ b/lisp/reposition.el
@@ -172,6 +172,8 @@ reposition-window
;; Return number of screen lines between START and END.
(defun repos-count-screen-lines (start end)
+ ;; Make sure jit-lock doesn't have to run in a narrowed context.
+ (font-lock-ensure start end)
(save-excursion
(save-restriction
(narrow-to-region start end)
>>> Could you, perhaps, suggest some alternative to using widen in
>>> c-font-lock-fontify-region? Some way which would still work for CC
>>> Mode (including the just fixed bug), but wouldn't adversely affect
>>> the several major mode code you're maintaining? Would it be
>>> possible to widen "a bit" rather than widening to the whole buffer?
>>> If so, how would I determine the bit to widen to?
>
>> Not sure what difference the supposed "bit" would make (and thus, how
>> would mmm-mode determine it).
>
> I was thinking about, perhaps, widening no wider than the CC Mode
> portion of the several major mode buffer.
That would normally be what the buffer is narrowed to already. Though I
suppose we could also offer a function that would re-narrow to these
bounds on demand.
>> But I think that would depend on your answer to my first question in
>> this email. Because, I think, normally you don't "have to" widen at
>> all, font-lock will do that for you.
>
> I think it does, normally, but it didn't when the font locking was
> invoked for vertical-motion. (Font locking is needed to determine the
> faces used, which might have different vertical sizes.)
Yes. I never thought about this before.
>> In mmm-mode context, however, we apply definite boundaries to the
>> region chunks. Here's an example of some Noweb code:
>> https://en.wikipedia.org/wiki/Noweb#Example_of_a_simple_noweb_program
>
>> The inside of hello.c block would be narrowed to.
>
> I think I've said this before, but I don't think narrowing is the right
> tool for that task. I don't think there is a suitable tool in Emacs at
> the moment.
*shrug* We do the best with what we have.
>> Now, I have remembered that CC Mode calls widen from many places
>> already, so it already is problematic for using in a context like that.
>
> It does, yes. Users also use widening and narrowing.
It's a different thing. Strategically undoing interactively applied
narrowing is not hard.
next prev parent reply other threads:[~2019-11-13 22:33 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 [this message]
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
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=6fc930a1-eb47-9e54-8752-8cf7ff041586@yandex.ru \
--to=dgutov@yandex.ru \
--cc=acm@muc.de \
--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.