From: Dmitry Gutov <dgutov@yandex.ru>
To: Alan Mackenzie <acm@muc.de>
Cc: 21871@debbugs.gnu.org
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 [thread overview]
Message-ID: <37a9ca07-1ffc-b872-4cf0-719f97177e35@yandex.ru> (raw)
In-Reply-To: <20160516102002.GB2317@acm.fritz.box>
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.
next prev parent reply other threads:[~2016-05-16 13:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-10 16:30 bug#21871: Emacs Lisp Mode (at least): spurious parens in column 0 don't get bold red highlighting Alan Mackenzie
[not found] ` <mailman.2066.1447172952.7904.bug-gnu-emacs@gnu.org>
2015-11-12 12:44 ` Alan Mackenzie
2015-11-12 16:36 ` Glenn Morris
2015-11-12 18:12 ` Alan Mackenzie
[not found] ` <mailman.2173.1447351928.7904.bug-gnu-emacs@gnu.org>
2015-11-12 18:54 ` Alan Mackenzie
2015-11-12 19:17 ` Eli Zaretskii
2016-05-15 21:50 ` Dmitry Gutov
2016-05-16 10:20 ` Alan Mackenzie
2016-05-16 13:18 ` Dmitry Gutov [this message]
2016-05-16 15:00 ` Andreas Röhler
2016-05-17 9:02 ` Alan Mackenzie
2017-09-02 13:19 ` Eli Zaretskii
2020-04-11 15:00 ` Noam Postavsky
2021-09-19 22:14 ` Stefan Kangas
2021-09-20 17:50 ` Alan Mackenzie
2021-09-21 23:07 ` Stefan Kangas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=37a9ca07-1ffc-b872-4cf0-719f97177e35@yandex.ru \
--to=dgutov@yandex.ru \
--cc=21871@debbugs.gnu.org \
--cc=acm@muc.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).