[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#38049: C mode fontification broken with reposition-window
From: |
Alan Mackenzie |
Subject: |
bug#38049: C mode fontification broken with reposition-window |
Date: |
Tue, 5 Nov 2019 21:07:37 +0000 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
Hello, Juri.
On Sun, Nov 03, 2019 at 22:28:05 +0200, Juri Linkov wrote:
> Version: 27.0.50
> 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.
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.
As Stefan M has sometimes remarked, narrowing is often not a good idea.
It would seem undesirable for the vertical-motion in (iii) to trigger
font-locking, since it is merely trying to count lines. Perhaps there
should be a macro `without-fontifying' which could be wrapped around
this call to vertical-motion, if there isn't such a thing anyway.
Maybe there are other calls of vertical-motion which are similarly
dangerous.
--
Alan Mackenzie (Nuremberg, Germany).