bug-gnu-emacs
[Top][All Lists]
Advanced

[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.





reply via email to

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