[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21871: Emacs Lisp Mode (at least): spurious parens in column 0 don't
From: |
Dmitry Gutov |
Subject: |
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 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1 |
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.