* bug#22256: 25.0.50; multiline font-lock rules broken in C mode
@ 2015-12-28 10:19 Anders Lindgren
[not found] ` <mailman.1133.1451298006.843.bug-gnu-emacs@gnu.org>
0 siblings, 1 reply; 7+ messages in thread
From: Anders Lindgren @ 2015-12-28 10:19 UTC (permalink / raw)
To: 22256
[-- Attachment #1: Type: text/plain, Size: 5158 bytes --]
Hi!
In C and related modes, multiline font-lock rules no longer work as
expected. It looks like a few lines are highlighted, but not all of them.
For example:
Eval the following:
(defvar my-multiline-test-keywords
'(("^X"
("^.+$"
(progn (beginning-of-line)
(point-max))
nil
(0 'highlight)))))
(defun my-multiline-test-add ()
(interactive)
(font-lock-add-keywords nil my-multiline-test-keywords)
(font-lock-flush))
Insert the following in a new buffer:
X START OF A HIGHLIGHTED BLOCK
LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
Do:
M-x c-mode RET
M-x my-multiline-test-add RET
I expect the entire buffer to be highlighted. However, only the first eight
lines are highlighted. When the block is edited, different parts of the
block is highlighted and unhighlighted.
As a contrast, when `emacs-lisp-mode' is used, the entire block is
highlighted, and editing does not change the highlighting.
This worked as intended in Emacs 24.5.
-- Anders Lindgren
In GNU Emacs 25.0.50.60 (x86_64-apple-darwin14.5.0, NS appkit-1348.17
Version 10.10.5 (Build 14F27))
of 2015-12-28
Repository revision: e9916d8880561cc06b6cb73bafe7257b93ffbf4c
Windowing system distributor 'Apple', version 10.3.1348
Configured using:
'configure --without-dbus'
Configured features:
ACL ZLIB TOOLKIT_SCROLL_BARS NS
Important settings:
value of $LC_CTYPE: UTF-8
locale-coding-system: utf-8-unix
Major mode: C/l
Minor modes in effect:
preproc-font-lock-global-mode: t
preproc-font-lock-mode: t
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
abbrev-mode: t
Recent messages:
previous-line: Beginning of buffer [6 times]
Preproc-Font-Lock mode enabled in current buffer
Making completion list... [2 times]
Type C-x 1 to delete the help window.
Making completion list... [2 times]
previous-line: Beginning of buffer [4 times]
Saving file /Users/anders/emacs/src/bugs/multiline.c...
Wrote /Users/anders/emacs/src/bugs/multiline.c
Making completion list... [2 times]
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils pp help-fns dabbrev character-fold
misearch multi-isearch cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs cus-start cus-load
preproc-font-lock easy-mmode vc-dispatcher vc-svn seq byte-opt gv
bytecomp byte-compile cconv cl-extra help-mode easymenu cl-loaddefs
pcase cl-lib time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel ns-win term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote cocoa ns multi-tty
make-network-process emacs)
Memory information:
((conses 16 125810 6766)
(symbols 48 22477 0)
(miscs 40 92 691)
(strings 32 31081 19325)
(string-bytes 1 1057796)
(vectors 16 15058)
(vector-slots 8 499686 7007)
(floats 8 160 240)
(intervals 56 3315 21)
(buffers 976 15))
[-- Attachment #2: Type: text/html, Size: 5694 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#22256: 25.0.50; multiline font-lock rules broken in C mode
[not found] ` <mailman.1133.1451298006.843.bug-gnu-emacs@gnu.org>
@ 2015-12-29 21:06 ` Alan Mackenzie
2015-12-30 5:50 ` Anders Lindgren
0 siblings, 1 reply; 7+ messages in thread
From: Alan Mackenzie @ 2015-12-29 21:06 UTC (permalink / raw)
To: Anders Lindgren; +Cc: 22256
Hello, Anders.
In article <mailman.1133.1451298006.843.bug-gnu-emacs@gnu.org> you wrote:
> [-- text/plain, encoding 7bit, charset: UTF-8, 143 lines --]
> Hi!
> In C and related modes, multiline font-lock rules no longer work as
> expected. It looks like a few lines are highlighted, but not all of them.
> For example:
> Eval the following:
> (defvar my-multiline-test-keywords
> '(("^X"
> ("^.+$"
> (progn (beginning-of-line)
> (point-max))
> nil
> (0 'highlight)))))
> (defun my-multiline-test-add ()
> (interactive)
> (font-lock-add-keywords nil my-multiline-test-keywords)
> (font-lock-flush))
> Insert the following in a new buffer:
> X START OF A HIGHLIGHTED BLOCK
> LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> Do:
> M-x c-mode RET
> M-x my-multiline-test-add RET
> I expect the entire buffer to be highlighted. However, only the first eight
> lines are highlighted. When the block is edited, different parts of the
> block is highlighted and unhighlighted.
This is caused by the jit-lock mechanism. The first eight lines are 500
characters (jit-lock-chunk-size) rounded up to a whole number of lines.
What happens is this: when the first jit-lock-chunk (8 lines) is
fontified, the `fontified' property (the one the display engine uses) is
set only on these 8 lines. The `face' property is then set on all the
characters of the file, as requested by the my-multiline-test-keywords
form.
Next thing, jit-lock fontifies the next chunk of ~7 lines starting where
the `fontified' property is nil. The first thing done is to set
`fontified' on these ~7 lines, then the `face' property on them is
erased. There is now no matching font lock pattern to apply any new
faces to these ~7 lines, since the "X" is many lines back. The same
thing happens with the next 500 byte chunk, and so on till the end of the
buffer.
If you set `font-lock-support-mode' to nil and restart font locking, the
problem isn't apparent. (Then set the variable back to 'jit-lock-mode.)
This is a fundamental problem with jit-lock-mode: the assumption that
text to be fontified has no non-trivial context. This is a difficult
problem to solve in general. CC Mode uses some ad-hoc tricks to catch,
for example, long struct declarations.
> As a contrast, when `emacs-lisp-mode' is used, the entire block is
> highlighted, and editing does not change the highlighting.
I do not see this in Emacs 24.5. For me, even in emacs-lisp-mode, I
still see just the 8 lines being fontified. If you could give me a
recipe (starting from emacs-24.5 -Q) to reproduce this, I'd be very
interested.
> This worked as intended in Emacs 24.5.
> -- Anders Lindgren
> In GNU Emacs 25.0.50.60 (x86_64-apple-darwin14.5.0, NS appkit-1348.17
> Version 10.10.5 (Build 14F27))
> of 2015-12-28
> Repository revision: e9916d8880561cc06b6cb73bafe7257b93ffbf4c
> Windowing system distributor 'Apple', version 10.3.1348
> Configured using:
> 'configure --without-dbus'
> Configured features:
> ACL ZLIB TOOLKIT_SCROLL_BARS NS
> Important settings:
> value of $LC_CTYPE: UTF-8
> locale-coding-system: utf-8-unix
> Major mode: C/l
> Minor modes in effect:
> preproc-font-lock-global-mode: t
> preproc-font-lock-mode: t
> tooltip-mode: t
> global-eldoc-mode: t
> electric-indent-mode: t
> mouse-wheel-mode: t
> tool-bar-mode: t
> menu-bar-mode: t
> file-name-shadow-mode: t
> global-font-lock-mode: t
> font-lock-mode: t
> blink-cursor-mode: t
> auto-composition-mode: t
> auto-encryption-mode: t
> auto-compression-mode: t
> line-number-mode: t
> transient-mark-mode: t
> abbrev-mode: t
[ .... ]
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#22256: 25.0.50; multiline font-lock rules broken in C mode
2015-12-29 21:06 ` Alan Mackenzie
@ 2015-12-30 5:50 ` Anders Lindgren
2016-01-08 21:34 ` Anders Lindgren
0 siblings, 1 reply; 7+ messages in thread
From: Anders Lindgren @ 2015-12-30 5:50 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: 22256
[-- Attachment #1: Type: text/plain, Size: 6315 bytes --]
Hi!
I just realized that I missed one vital thing in the example I posted.
`font-lock-multiline' must be set. Also, I add code so that it works when
`font-lock-flush' isn't defined.
(defvar my-multiline-test-keywords
'(("^X"
("^.+$"
(progn (beginning-of-line)
(point-max))
nil
(0 'highlight)))))
(defun my-multiline-test-add ()
(interactive)
(font-lock-add-keywords nil my-multiline-test-keywords)
(setq font-lock-multiline t)
(if (fboundp 'font-lock-flush)
(font-lock-flush)
(when font-lock-mode
(with-no-warnings
(font-lock-fontify-buffer)))))
Recipe:
emacs -Q
Eval the code above
C-x b test RET
Insert the text starting with an X (from the first mail)
M-x c-mode RET
M-x my-multiline-test-add RET
Alternatively, use emacs-lisp-mode instead of C mode.
When tested on Emacs 24.5 and Emacs 25, the only combination that doesn't
work is Emacs 25 + C mode.
There are a number of font-lock packages that utilize that this work,
including my https://github.com/Lindydancer/preproc-font-lock package.
-- Anders
On Tue, Dec 29, 2015 at 10:06 PM, Alan Mackenzie <acm@muc.de> wrote:
>
> Hello, Anders.
>
> In article <mailman.1133.1451298006.843.bug-gnu-emacs@gnu.org> you wrote:
> > [-- text/plain, encoding 7bit, charset: UTF-8, 143 lines --]
>
> > Hi!
>
> > In C and related modes, multiline font-lock rules no longer work as
> > expected. It looks like a few lines are highlighted, but not all of
them.
>
> > For example:
> > Eval the following:
> > (defvar my-multiline-test-keywords
> > '(("^X"
> > ("^.+quot;
> > (progn (beginning-of-line)
> > (point-max))
> > nil
> > (0 'highlight)))))
>
> > (defun my-multiline-test-add ()
> > (interactive)
> > (font-lock-add-keywords nil my-multiline-test-keywords)
> > (font-lock-flush))
>
> > Insert the following in a new buffer:
>
> > X START OF A HIGHLIGHTED BLOCK
> > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
> > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK
>
> > Do:
> > M-x c-mode RET
> > M-x my-multiline-test-add RET
>
> > I expect the entire buffer to be highlighted. However, only the first
eight
> > lines are highlighted. When the block is edited, different parts of the
> > block is highlighted and unhighlighted.
>
> This is caused by the jit-lock mechanism. The first eight lines are 500
> characters (jit-lock-chunk-size) rounded up to a whole number of lines.
>
> What happens is this: when the first jit-lock-chunk (8 lines) is
> fontified, the `fontified' property (the one the display engine uses) is
> set only on these 8 lines. The `face' property is then set on all the
> characters of the file, as requested by the my-multiline-test-keywords
> form.
>
> Next thing, jit-lock fontifies the next chunk of ~7 lines starting where
> the `fontified' property is nil. The first thing done is to set
> `fontified' on these ~7 lines, then the `face' property on them is
> erased. There is now no matching font lock pattern to apply any new
> faces to these ~7 lines, since the "X" is many lines back. The same
> thing happens with the next 500 byte chunk, and so on till the end of the
> buffer.
>
> If you set `font-lock-support-mode' to nil and restart font locking, the
> problem isn't apparent. (Then set the variable back to 'jit-lock-mode.)
>
> This is a fundamental problem with jit-lock-mode: the assumption that
> text to be fontified has no non-trivial context. This is a difficult
> problem to solve in general. CC Mode uses some ad-hoc tricks to catch,
> for example, long struct declarations.
>
> > As a contrast, when `emacs-lisp-mode' is used, the entire block is
> > highlighted, and editing does not change the highlighting.
>
> I do not see this in Emacs 24.5. For me, even in emacs-lisp-mode, I
> still see just the 8 lines being fontified. If you could give me a
> recipe (starting from emacs-24.5 -Q) to reproduce this, I'd be very
> interested.
>
> > This worked as intended in Emacs 24.5.
>
> > -- Anders Lindgren
>
> > In GNU Emacs 25.0.50.60 (x86_64-apple-darwin14.5.0, NS appkit-1348.17
> > Version 10.10.5 (Build 14F27))
> > of 2015-12-28
> > Repository revision: e9916d8880561cc06b6cb73bafe7257b93ffbf4c
> > Windowing system distributor 'Apple', version 10.3.1348
> > Configured using:
> > 'configure --without-dbus'
>
> > Configured features:
> > ACL ZLIB TOOLKIT_SCROLL_BARS NS
>
> > Important settings:
> > value of $LC_CTYPE: UTF-8
> > locale-coding-system: utf-8-unix
>
> > Major mode: C/l
>
> > Minor modes in effect:
> > preproc-font-lock-global-mode: t
> > preproc-font-lock-mode: t
> > tooltip-mode: t
> > global-eldoc-mode: t
> > electric-indent-mode: t
> > mouse-wheel-mode: t
> > tool-bar-mode: t
> > menu-bar-mode: t
> > file-name-shadow-mode: t
> > global-font-lock-mode: t
> > font-lock-mode: t
> > blink-cursor-mode: t
> > auto-composition-mode: t
> > auto-encryption-mode: t
> > auto-compression-mode: t
> > line-number-mode: t
> > transient-mark-mode: t
> > abbrev-mode: t
>
> [ .... ]
>
> --
> Alan Mackenzie (Nuremberg, Germany).
>
[-- Attachment #2: Type: text/html, Size: 8087 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#22256: 25.0.50; multiline font-lock rules broken in C mode
2015-12-30 5:50 ` Anders Lindgren
@ 2016-01-08 21:34 ` Anders Lindgren
2016-01-09 12:19 ` Alan Mackenzie
0 siblings, 1 reply; 7+ messages in thread
From: Anders Lindgren @ 2016-01-08 21:34 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: 22256
[-- Attachment #1: Type: text/plain, Size: 7340 bytes --]
Hi Alan (and the list),
I made a "git bisect" and found the culprit:
--------
b31d359d182eb252a11f0468a7dc1ee1eafb28e9 is the first bad commit
commit b31d359d182eb252a11f0468a7dc1ee1eafb28e9
Author: Alan Mackenzie <acm@muc.de>
Date: Sun Feb 1 21:20:35 2015 +0000
CC Mode: Stop Font Lock forcing fontification from BOL. Fixes
debbugs#19669.
cc-mode.el (c-font-lock-init): Setq font-lock-extend-region-functions
to nil.
--------
The reason this breaks multiline keywords is that
`font-lock-extend-region-multiline' is normally part of
`font-lock-extend-region-functions'.
-- Anders
On Wed, Dec 30, 2015 at 6:50 AM, Anders Lindgren <andlind@gmail.com> wrote:
>
>
> Hi!
>
> I just realized that I missed one vital thing in the example I posted.
`font-lock-multiline' must be set. Also, I add code so that it works when
`font-lock-flush' isn't defined.
>
> (defvar my-multiline-test-keywords
> '(("^X"
> ("^.+quot;
> (progn (beginning-of-line)
> (point-max))
> nil
> (0 'highlight)))))
>
> (defun my-multiline-test-add ()
> (interactive)
> (font-lock-add-keywords nil my-multiline-test-keywords)
> (setq font-lock-multiline t)
> (if (fboundp 'font-lock-flush)
> (font-lock-flush)
> (when font-lock-mode
> (with-no-warnings
> (font-lock-fontify-buffer)))))
>
> Recipe:
>
> emacs -Q
> Eval the code above
> C-x b test RET
> Insert the text starting with an X (from the first mail)
> M-x c-mode RET
> M-x my-multiline-test-add RET
>
> Alternatively, use emacs-lisp-mode instead of C mode.
>
> When tested on Emacs 24.5 and Emacs 25, the only combination that doesn't
work is Emacs 25 + C mode.
>
> There are a number of font-lock packages that utilize that this work,
including my https://github.com/Lindydancer/preproc-font-lock package.
>
> -- Anders
>
> On Tue, Dec 29, 2015 at 10:06 PM, Alan Mackenzie <acm@muc.de> wrote:
> >
> > Hello, Anders.
> >
> > In article <mailman.1133.1451298006.843.bug-gnu-emacs@gnu.org> you
wrote:
> > > [-- text/plain, encoding 7bit, charset: UTF-8, 143 lines --]
> >
> > > Hi!
> >
> > > In C and related modes, multiline font-lock rules no longer work as
> > > expected. It looks like a few lines are highlighted, but not all of
them.
> >
> > > For example:
> > > Eval the following:
> > > (defvar my-multiline-test-keywords
> > > '(("^X"
> > > ("^.+quot;
>
> > > (progn (beginning-of-line)
> > > (point-max))
> > > nil
> > > (0 'highlight)))))
> >
> > > (defun my-multiline-test-add ()
> > > (interactive)
> > > (font-lock-add-keywords nil my-multiline-test-keywords)
> > > (font-lock-flush))
> >
> > > Insert the following in a new buffer:
> >
> > > X START OF A HIGHLIGHTED BLOCK
> > > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE
BLOCK
> > > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE
BLOCK
> > > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE
BLOCK
> > > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE
BLOCK
> > > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE
BLOCK
> > > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE
BLOCK
> > > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE
BLOCK
> > > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE
BLOCK
> > > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE
BLOCK
> > > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE
BLOCK
> > > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE
BLOCK
> > > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE
BLOCK
> > > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE
BLOCK
> > > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE
BLOCK
> > > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE
BLOCK
> > > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE
BLOCK
> > > LONG LINES IN THE BLOCK LONG LINES IN THE BLOCK LONG LINES IN THE
BLOCK
> >
> > > Do:
> > > M-x c-mode RET
> > > M-x my-multiline-test-add RET
> >
> > > I expect the entire buffer to be highlighted. However, only the first
eight
> > > lines are highlighted. When the block is edited, different parts of
the
> > > block is highlighted and unhighlighted.
> >
> > This is caused by the jit-lock mechanism. The first eight lines are 500
> > characters (jit-lock-chunk-size) rounded up to a whole number of lines.
> >
> > What happens is this: when the first jit-lock-chunk (8 lines) is
> > fontified, the `fontified' property (the one the display engine uses) is
> > set only on these 8 lines. The `face' property is then set on all the
> > characters of the file, as requested by the my-multiline-test-keywords
> > form.
> >
> > Next thing, jit-lock fontifies the next chunk of ~7 lines starting where
> > the `fontified' property is nil. The first thing done is to set
> > `fontified' on these ~7 lines, then the `face' property on them is
> > erased. There is now no matching font lock pattern to apply any new
> > faces to these ~7 lines, since the "X" is many lines back. The same
> > thing happens with the next 500 byte chunk, and so on till the end of
the
> > buffer.
> >
> > If you set `font-lock-support-mode' to nil and restart font locking, the
> > problem isn't apparent. (Then set the variable back to 'jit-lock-mode.)
> >
> > This is a fundamental problem with jit-lock-mode: the assumption that
> > text to be fontified has no non-trivial context. This is a difficult
> > problem to solve in general. CC Mode uses some ad-hoc tricks to catch,
> > for example, long struct declarations.
> >
> > > As a contrast, when `emacs-lisp-mode' is used, the entire block is
> > > highlighted, and editing does not change the highlighting.
> >
> > I do not see this in Emacs 24.5. For me, even in emacs-lisp-mode, I
> > still see just the 8 lines being fontified. If you could give me a
> > recipe (starting from emacs-24.5 -Q) to reproduce this, I'd be very
> > interested.
> >
> > > This worked as intended in Emacs 24.5.
> >
> > > -- Anders Lindgren
> >
> > > In GNU Emacs 25.0.50.60 (x86_64-apple-darwin14.5.0, NS appkit-1348.17
> > > Version 10.10.5 (Build 14F27))
> > > of 2015-12-28
> > > Repository revision: e9916d8880561cc06b6cb73bafe7257b93ffbf4c
> > > Windowing system distributor 'Apple', version 10.3.1348
> > > Configured using:
> > > 'configure --without-dbus'
> >
> > > Configured features:
> > > ACL ZLIB TOOLKIT_SCROLL_BARS NS
> >
> > > Important settings:
> > > value of $LC_CTYPE: UTF-8
> > > locale-coding-system: utf-8-unix
> >
> > > Major mode: C/l
> >
> > > Minor modes in effect:
> > > preproc-font-lock-global-mode: t
> > > preproc-font-lock-mode: t
> > > tooltip-mode: t
> > > global-eldoc-mode: t
> > > electric-indent-mode: t
> > > mouse-wheel-mode: t
> > > tool-bar-mode: t
> > > menu-bar-mode: t
> > > file-name-shadow-mode: t
> > > global-font-lock-mode: t
> > > font-lock-mode: t
> > > blink-cursor-mode: t
> > > auto-composition-mode: t
> > > auto-encryption-mode: t
> > > auto-compression-mode: t
> > > line-number-mode: t
> > > transient-mark-mode: t
> > > abbrev-mode: t
> >
> > [ .... ]
> >
> > --
> > Alan Mackenzie (Nuremberg, Germany).
> >
[-- Attachment #2: Type: text/html, Size: 9684 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#22256: 25.0.50; multiline font-lock rules broken in C mode
2016-01-08 21:34 ` Anders Lindgren
@ 2016-01-09 12:19 ` Alan Mackenzie
2016-01-09 13:40 ` Anders Lindgren
0 siblings, 1 reply; 7+ messages in thread
From: Alan Mackenzie @ 2016-01-09 12:19 UTC (permalink / raw)
To: Anders Lindgren; +Cc: 22256
Hello, Anders.
Thanks for doing all the donkey work.
On Fri, Jan 08, 2016 at 10:34:09PM +0100, Anders Lindgren wrote:
> Hi Alan (and the list),
> I made a "git bisect" and found the culprit:
> --------
> b31d359d182eb252a11f0468a7dc1ee1eafb28e9 is the first bad commit
> commit b31d359d182eb252a11f0468a7dc1ee1eafb28e9
> Author: Alan Mackenzie <acm@muc.de>
> Date: Sun Feb 1 21:20:35 2015 +0000
> CC Mode: Stop Font Lock forcing fontification from BOL. Fixes
> debbugs#19669.
> cc-mode.el (c-font-lock-init): Setq font-lock-extend-region-functions
> to nil.
> --------
> The reason this breaks multiline keywords is that
> `font-lock-extend-region-multiline' is normally part of
> `font-lock-extend-region-functions'.
OK. The fix is then fairly obvious: to remove the one function from
`font-lock-extend-region-functions' which was causing the problem,
leaving the other functions (in particular
`font-lock-extend-region-multiline') in place.
Could you try out this patch, please. It seems to work OK for me, here.
diff -r a73bd5d1bd06 cc-mode.el
--- a/cc-mode.el Fri Jan 08 22:25:59 2016 +0000
+++ b/cc-mode.el Sat Jan 09 12:00:10 2016 +0000
@@ -1324,12 +1324,13 @@
. c-mark-function)))
;; Prevent `font-lock-default-fontify-region' extending the region it will
- ;; fontify to whole lines by removing `font-lock-extend-region-whole-lines'
- ;; (and, coincidentally, `font-lock-extend-region-multiline' (which we do
- ;; not need)) from `font-lock-extend-region-functions'. (Emacs only). This
- ;; fixes Emacs bug #19669.
+ ;; fontify to whole lines by removing `font-lock-extend-region-wholelines'
+ ;; from `font-lock-extend-region-functions'. (Emacs only). This fixes
+ ;; Emacs bug #19669.
(when (boundp 'font-lock-extend-region-functions)
- (setq font-lock-extend-region-functions nil))
+ (setq font-lock-extend-region-functions
+ (delq 'font-lock-extend-region-wholelines
+ font-lock-extend-region-functions)))
(make-local-variable 'font-lock-fontify-region-function)
(setq font-lock-fontify-region-function 'c-font-lock-fontify-region)
> -- Anders
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#22256: 25.0.50; multiline font-lock rules broken in C mode
2016-01-09 12:19 ` Alan Mackenzie
@ 2016-01-09 13:40 ` Anders Lindgren
2016-01-09 15:25 ` Alan Mackenzie
0 siblings, 1 reply; 7+ messages in thread
From: Anders Lindgren @ 2016-01-09 13:40 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: 22256
[-- Attachment #1: Type: text/plain, Size: 2499 bytes --]
Hi!
I just tested this and I can verify that this solved my multiline problem.
Thanks!
-- Anders
On Sat, Jan 9, 2016 at 1:19 PM, Alan Mackenzie <acm@muc.de> wrote:
> Hello, Anders.
>
> Thanks for doing all the donkey work.
>
> On Fri, Jan 08, 2016 at 10:34:09PM +0100, Anders Lindgren wrote:
> > Hi Alan (and the list),
>
> > I made a "git bisect" and found the culprit:
>
> > --------
> > b31d359d182eb252a11f0468a7dc1ee1eafb28e9 is the first bad commit
> > commit b31d359d182eb252a11f0468a7dc1ee1eafb28e9
> > Author: Alan Mackenzie <acm@muc.de>
> > Date: Sun Feb 1 21:20:35 2015 +0000
>
> > CC Mode: Stop Font Lock forcing fontification from BOL. Fixes
> > debbugs#19669.
> > cc-mode.el (c-font-lock-init): Setq font-lock-extend-region-functions
> > to nil.
> > --------
>
> > The reason this breaks multiline keywords is that
> > `font-lock-extend-region-multiline' is normally part of
> > `font-lock-extend-region-functions'.
>
> OK. The fix is then fairly obvious: to remove the one function from
> `font-lock-extend-region-functions' which was causing the problem,
> leaving the other functions (in particular
> `font-lock-extend-region-multiline') in place.
>
> Could you try out this patch, please. It seems to work OK for me, here.
>
>
>
> diff -r a73bd5d1bd06 cc-mode.el
> --- a/cc-mode.el Fri Jan 08 22:25:59 2016 +0000
> +++ b/cc-mode.el Sat Jan 09 12:00:10 2016 +0000
> @@ -1324,12 +1324,13 @@
> . c-mark-function)))
>
> ;; Prevent `font-lock-default-fontify-region' extending the region it
> will
> - ;; fontify to whole lines by removing
> `font-lock-extend-region-whole-lines'
> - ;; (and, coincidentally, `font-lock-extend-region-multiline' (which we
> do
> - ;; not need)) from `font-lock-extend-region-functions'. (Emacs only).
> This
> - ;; fixes Emacs bug #19669.
> + ;; fontify to whole lines by removing
> `font-lock-extend-region-wholelines'
> + ;; from `font-lock-extend-region-functions'. (Emacs only). This fixes
> + ;; Emacs bug #19669.
> (when (boundp 'font-lock-extend-region-functions)
> - (setq font-lock-extend-region-functions nil))
> + (setq font-lock-extend-region-functions
> + (delq 'font-lock-extend-region-wholelines
> + font-lock-extend-region-functions)))
>
> (make-local-variable 'font-lock-fontify-region-function)
> (setq font-lock-fontify-region-function 'c-font-lock-fontify-region)
>
>
> > -- Anders
>
> --
> Alan Mackenzie (Nuremberg, Germany).
>
[-- Attachment #2: Type: text/html, Size: 3363 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#22256: 25.0.50; multiline font-lock rules broken in C mode
2016-01-09 13:40 ` Anders Lindgren
@ 2016-01-09 15:25 ` Alan Mackenzie
0 siblings, 0 replies; 7+ messages in thread
From: Alan Mackenzie @ 2016-01-09 15:25 UTC (permalink / raw)
To: Anders Lindgren; +Cc: 22256-done
Hello, Anders.
On Sat, Jan 09, 2016 at 02:40:24PM +0100, Anders Lindgren wrote:
> Hi!
> I just tested this and I can verify that this solved my multiline problem.
> Thanks!
Well, thank you! I've committed that change, and I'm closing the bug as
fixed.
> -- Anders
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-01-09 15:25 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-12-28 10:19 bug#22256: 25.0.50; multiline font-lock rules broken in C mode Anders Lindgren
[not found] ` <mailman.1133.1451298006.843.bug-gnu-emacs@gnu.org>
2015-12-29 21:06 ` Alan Mackenzie
2015-12-30 5:50 ` Anders Lindgren
2016-01-08 21:34 ` Anders Lindgren
2016-01-09 12:19 ` Alan Mackenzie
2016-01-09 13:40 ` Anders Lindgren
2016-01-09 15:25 ` Alan Mackenzie
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).