emacs-devel
[Top][All Lists]
Advanced

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

Re: font-lock-syntactic-keywords obsolet?


From: Alan Mackenzie
Subject: Re: font-lock-syntactic-keywords obsolet?
Date: Thu, 23 Jun 2016 16:30:21 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

Hello, Dmitry.

On Wed, Jun 22, 2016 at 02:50:58AM +0300, Dmitry Gutov wrote:
> On 06/21/2016 05:40 PM, Alan Mackenzie wrote:

> > Yes, no, and N/A, respectively.  Try out this raw string support,
> > sometime.

> Here's some results: a performance degradation example, and a way to 
> break CC Mode, apparently.

Thanks for doing this test and telling me about it.

> First, paste this near the top of xdisp.c (I did it after the big 
> comment and before the header includes, but this is probably not too 
> important):

> const char* s1 = R"foo(
> Hello
> World
> )foo";

> and switch to c++-mode.

> 1) Delete the last double-quote, then type it again. Deletion is 
> noticeably slow (even though bearably so: feels like 0.5 sec), restoring 
> it is faster.

Yes.  There were two functions in cc-fonts.el that were using
(point-max) as a limit for something, when they should have been using,
respectively, (min limit (point-max)), and limit.  A bit of playing
around suggests there is more to fix, there.

> 2) Delete the first double-quote, then type it again. Get this backtrace:

> Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
>    c-after-change-re-mark-raw-strings(15101 15102 0)
>    #[(fn) "  \n#\207" [fn beg end old-len] 
> 4](c-after-change-re-mark-raw-strings)
>    mapc(#[(fn) "     \n#\207" [fn beg end old-len] 4] 
> (c-extend-font-lock-region-for-macros c-after-change-re-mark-raw-strings 
> c-neutralize-syntax-in-and-mark-CPP c-restore-<>-properties 
> c-change-expand-fl-region))
>    c-after-change(15101 15102 0)
>    self-insert-command(1)
>    funcall-interactively(self-insert-command 1)
>    call-interactively(self-insert-command nil nil)
>    command-execute(self-insert-command)

Yes.  This was caused by a low level function failing to do
(save-match-data ...) around a (looking-at ....) with the result that
the match-data was corrupted for the higher level function.  That bug's
been there for some while.

> This scenario is really the first thing I've tried.

Thanks.  I've just committed a patch which should fix your exact
scenario.  As I said, there's a little more to do.

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

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