[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#37137: Setting font-lock-case-fold-search to t causes hangs on certa
From: |
Alan Mackenzie |
Subject: |
bug#37137: Setting font-lock-case-fold-search to t causes hangs on certain types in c-mode |
Date: |
25 Aug 2019 10:22:26 -0000 |
User-agent: |
tin/2.4.2-20171224 ("Lochhead") (UNIX) (FreeBSD/11.2-RELEASE-p9 (amd64)) |
Hello, Zachary.
In article <mailman.18.1566429065.1922.bug-gnu-emacs@gnu.org> you wrote:
> [-- text/plain, encoding 7bit, charset: UTF-8, 31 lines --]
> I have in my .emacs file only these two lines:
> (custom-set-variables
> '(font-lock-keywords-case-fold-search t))
May I ask why you're making this setting?
I think font-lock-keywords-case-fold-search is really intended to be set
by major modes, rather than as a user customisation.
> Then if I visit an empty or nonexistent C file and just type "LONG"
> (in all caps or with at least one letter being capital), Emacs will
> hang after typing the final G but before the G appears on
> screen. Typing C-g a couple of times gets Emacs unstuck until I
> continue to type. The same behavior also happens if I type "SHORT".
Yes. The keywords in all the CC Mode languages are case sensitive.
Almost exactly the same bug came up in 2013, when the solution was to
bind case-fold-search to nil at every "entry point" to CC Mode. I missed
font-lock-keywords-case-fold-search at the time.
> This happens in both Emacs 26.1 in text mode on a Linux machine and in
> Emacs 25.3 in GUI mode on Windows.
> After messing with GDB a bit, I am pretty sure the hang is at the
> while loop in c-forward-type at cc-engine.el:7657 and its getting
> stuck because looking-at matches LONG because its case insensitive,
> but the c-forward-keyword-clause doesn't move forward because the
> first thing it does is try to find "LONG" in c-keywords-obarray via
> `intern-soft` and immediately returns because it doesn't find it
> there. Here is the while loop:
> (while (progn
> (setq safe-pos (point))
> (looking-at c-opt-type-component-key))
> (when (and c-record-type-identifiers
> (looking-at c-primitive-type-key))
> (c-record-type-id (cons (match-beginning 1)
> (match-end 1))))
> (c-forward-keyword-clause 1))
That's an excellent piece of debugging. :-)
I think the best fix for the bug would be for CC Mode to set
font-lock-keywords-case-fold-search explicitly to nil (buffer locally) at
C Mode (etc.) initialisation. This would undo the effect of your
custom-set-variables form in C Mode buffers. Would this be a problem?
--
Alan Mackenzie (Nuremberg, Germany).