bug-gnu-emacs
[Top][All Lists]
Advanced

[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).





reply via email to

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