[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10664: 24.0.93; JIT font-lock infloops in a C file
From: |
Eli Zaretskii |
Subject: |
bug#10664: 24.0.93; JIT font-lock infloops in a C file |
Date: |
Wed, 08 Feb 2012 19:49:58 +0200 |
> Date: Wed, 8 Feb 2012 11:47:49 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, 10664@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
>
> #########################################################################
> 1 template <typename T>
> 2
> 3
> 4 void myfunc(T* p) {}
> #########################################################################
>
> This is fontified correctly. Type a space on L2. This is OK for half a
> second, then context fontification messes up L4. The correct
> fontification can only be restored by a change to L4.
>
> Revision #106729 fixes this problem, after a space on L2, by making the
> fontification start at L1 rather than L2.
>
> The exact mechanism of why the problem happened is buried in my log, and
> I could dredge it up if you're really interested.
>
> The problem with this approach is demonstrated in Eli's socket.c:
>
> SCM_DEFINE (scm_inet_pton, "inet-pton", 2, 0, 0,
> (SCM family, SCM address),
> "Convert a string containing a printable network address to\n"
> "an integer address. Note that unlike the C version of this\n"
> "function,\n"
> "the result is an integer with normal host byte ordering.\n"
> "@var{family} can be @code{AF_INET} or @code{AF_INET6}.
> E.g.,\n\n"
> "@lisp\n"
> "(inet-pton AF_INET \"127.0.0.1\") @result{} 2130706433\n"
> "(inet-pton AF_INET6 \"::1\") @result{} 1\n"
> "@end lisp")
> #define FUNC_NAME s_scm_inet_pton
> {
>
> A 500 byte chunk of fontification ends just before "@end lisp". For
> this line, the start of the next chunk is "pushed back" to the
> SCM_DEFINE line to get a proper context for "@end lisp". It then
> repeatedly fontifies the same chunk.
>
> Interestingly, EOL just before "@end lisp" is exactly 500 bytes after
> the initial scm_inet_pton.
Thanks for explaining this.
Would it fix the problem if, when jit-lock is "pushed back" by N >= 500
characters, it will fontify N + n characters, where n > 0 ? (E.g., set
n = 100.)
- bug#10664: 24.0.93; JIT font-lock infloops in a C file, Eli Zaretskii, 2012/02/05
- bug#10664: 24.0.93; JIT font-lock infloops in a C file, Alan Mackenzie, 2012/02/06
- bug#10664: 24.0.93; JIT font-lock infloops in a C file, Stefan Monnier, 2012/02/06
- bug#10664: 24.0.93; JIT font-lock infloops in a C file, Eli Zaretskii, 2012/02/06
- bug#10664: 24.0.93; JIT font-lock infloops in a C file, Eli Zaretskii, 2012/02/07
- bug#10664: 24.0.93; JIT font-lock infloops in a C file, Alan Mackenzie, 2012/02/07
- bug#10664: 24.0.93; JIT font-lock infloops in a C file, Eli Zaretskii, 2012/02/07
- bug#10664: 24.0.93; JIT font-lock infloops in a C file, Alan Mackenzie, 2012/02/07
- bug#10664: 24.0.93; JIT font-lock infloops in a C file, Stefan Monnier, 2012/02/07
- bug#10664: 24.0.93; JIT font-lock infloops in a C file, Alan Mackenzie, 2012/02/08
- bug#10664: 24.0.93; JIT font-lock infloops in a C file,
Eli Zaretskii <=
- bug#10664: 24.0.93; JIT font-lock infloops in a C file, Stefan Monnier, 2012/02/08
- bug#10664: 24.0.93; JIT font-lock infloops in a C file, Alan Mackenzie, 2012/02/10
- bug#10664: 24.0.93; JIT font-lock infloops in a C file, Eli Zaretskii, 2012/02/12
- bug#10664: 24.0.93; JIT font-lock infloops in a C file, Chong Yidong, 2012/02/14