emacs-devel
[Top][All Lists]
Advanced

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

Re: master 7362554: Widen around c-font-lock-fontify-region. This fixes


From: Dmitry Gutov
Subject: Re: master 7362554: Widen around c-font-lock-fontify-region. This fixes bug #38049.
Date: Thu, 14 Nov 2019 00:33:33 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

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.



reply via email to

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