GNU bug report logs - #21871
Emacs Lisp Mode (at least): spurious parens in column 0 don't get bold red highlighting.

Previous Next

Full log

Message #32 received at 21871 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 21871 <at> debbugs.gnu.org
Subject: Re: bug#21871: Emacs Lisp Mode (at least): spurious parens in column
 0 don't get bold red highlighting.
Date: Mon, 16 May 2016 16:18:54 +0300

On 05/16/2016 01:20 PM, Alan Mackenzie wrote:

> Note this convention is still active.

The "convention" may be in place, but the underlying reasons for it  are 
much weaker these days. Any relevant operation can use syntax-ppss.

>> We don't have to scan back to the beginning of the buffer, we can use
>> syntax-ppss (and it's more reliable with bug#16247 fixed).
>
> Sorry, this isn't true.  The scanning back to BOB is done at the C
> level, in function back_comment.

What I wrote is true: font-lock rules can use syntax-ppss, and often do.

> syntax-ppss isn't suitable for use
> here (Stefan's view, not merely mine), because syntax-ppss doesn't react
> to changes in the syntax table, and suchlike.

Here where?

>> font-lock doesn't get confused by something looking like a defun inside
>> a docstring (try it; I wasn't able to get it highlight something wrong).
>
> You might be getting confused, here.

No, I'm not. I'm addressing a comment inside font-lock-compile-keywords, 
which is trying to justify highlighting parens in the first column.

> The scanning back to BOB which is
> slow doesn't just happen in font lock; it can (and does) happen
> anywhere.

Only in certain places, where the programmer didn't think to use the 
cache provided by syntax-ppss.

> It's just font lock's job to warn the user about this, so
> that she can correct it by adding in a backslash, for example.

And it's the job of the programmer to avoid this problem altogether, 
which is not too hard.

> Things do get confused, for example see bug #22884, where there was an
> open paren in column zero in our own C sources.

Even if bug#22884 is somewhat related, it's actually irrelevant is the 
current discussion because c-mode uses a non-default 
beginning-of-defun-function. Which means font-lock-compile-keywords 
won't add highlighting to 0-column parens in c-mode anyway.

It seems the current code was designed with only Lisp modes in mind.

>> M-x beginning-of-defun does get confused, though. If *that* is problem
>> what we want to detect, .....
>
> Not particularly.  We want the user to be warned about things
> potentially going wrong in back_comment, and anything which calls it.

I don't see any reason to believe that the original author of this code 
was concerned with back_comment specifically.

> No.  open-paren-in-column-0-is-defun-start is a variable that the user
> can change at any time.

I don't think it is, or should be, true. The major mode knows better 
whether it can know where a defun starts, or not.

E.g. js-mode and elisp-byte-code-mode set it to nil. If the user changes 
that value in one of these modes, nothing good will happen.

> We can't make our font-locking dependent upon
> what its value was at some time in the past.  If open-paren-... belongs
> anywhere, it's in the form just beyond the end of your patch's text.

I don't think so. I don't mind taking its comparison out altogether, but 
then the predicate will become very simple.

> Do you understand the consequences of taking out the check on
> syntax-begin-function?  (I certainly don't.)  It would be good if Stefan
> could express a view, here.

Point is, there is no way to simply alter the check that it would accept 
the current situation with syntax-begin-function, but still keep it 
meaningful. If we accept the value nil (which it is emacs-lisp-mode 
now), we should accept any syntax-begin-function, I think.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.