From: "Andreas Röhler" <andreas.roehler@easy-emacs.de>
To: 31290@debbugs.gnu.org
Subject: bug#31290: Fundamental bugs in syntax-propertize
Date: Sun, 13 May 2018 09:33:20 +0200 [thread overview]
Message-ID: <79bd61c9-1d9c-d2f4-9206-3623a0553ff1@easy-emacs.de> (raw)
In-Reply-To: <20180512112612.GA4766@ACM>
On 12.05.2018 13:26, Alan Mackenzie wrote:
> Hello, Dmitry.
>
> On Tue, May 08, 2018 at 15:35:14 +0300, Dmitry Gutov wrote:
>> On 4/28/18 12:08 AM, Alan Mackenzie wrote:
>
>>> At least that would be true if syntax-propertize--done hadn't been
>>> prematurely and spuriously increased, crudely to prevent an infinite
>>> recursion, falsely indicating to the syntax-ppss infrastructure that the
>>> syntax-table properties have already been applied to the region (BEGIN
>>> END).
>
>>> .... but it should not call `syntax-ppss-flush-cache', ....
>
>>> Why not? Because syntax-ppss-flush-cache sets syntax-propertize--done
>>> back to its true value, allowing the wrongly allowed syntax-ppss calls at
>>> a later position to cause a recursive loop.
>
>> Maybe we should "allow" it to loop, in certain cases? Leaving it to be
>> the responsibility of the programmer, to make sure the result doesn't
>> infloop, even if these rules are violated.
>
> I'm not sure how this could work. We would need to formalise the rules
> very carefully, to avoid the need to read syntax.{c,el}'s source code.
>
>>> .... which means that it should not call `syntax-ppss' on some
>>> position and later modify the buffer on some earlier position.
>
>>> This is a bad restriction, because sometimes syntax-table properties can
>>> only be correctly determined by examining the syntax of later buffer
>>> positions. An example of this is giving the string-fence syntax-table
>>> text property to an unbalanced opening string quote, but not to correctly
>>> matched quotes.
>
>> I'm not exactly convinced by the given example (why would we use the
>> string-fence in that case?), but it might be better if something like
>> this was possible, indeed.
>
> String fence can be used to signal to font lock that the delimiter
> (together with the "mismatching" unescaped EOL) should be fontified in
> warning face.
>
> A better example might be C++ Mode's marking of a "< ... >" pair with
> paren syntax. This isn't done with syntax-propertize-function (as you
> know), but it would be nice if this were possible.
>
>>> 2. syntax-propertize-function's are banned from using syntax-ppss, the
>>> documentation instead directing them to use parse-partial-sexp directly.
>
>> The ones that currently call syntax-ppss, can't simply switch over to
>> parse-partial-sexp without becoming slower due to the lack of cache.
>
> The cache at the pertinent buffer position doesn't exist at the time:
> consistent syntax-table properties aren't on the preceding buffer
> positions.
>
>> Before tackling this bug, I'd rather we see a real-world problem that it
>> caused, and pick a particular approach based on it.
>
> My enhancements for bug#30393: "24.4; cperl-mode: indentation failure -
> Documentation enhancements", where (almost) any change which affects the
> syntactic state is programmed to call syntax-ppss-flush-cache from the C
> level, clashes with the mechanism in this bug report. Most of the time
> it's fine, but when a change affecting the syntactic state is made from
> inside a synax-propertize-function, Emacs goes into an infinite recursive
> loop.
>
> This isn't good.
>
>> But off the top of my head, we could introduce a "stricter but somewhat
>> slower" variation of syntax-ppss to be called inside
>> syntax-propertize-function's, which would treat the values in question
>> more carefully, somehow.
>
> That's an idea worth exploring.
>
Hi folks,
from what I've seen month ago just may stress the term fundamental.
Gave up to follow details WRT to check-ins made.
That part needs some person treating the gordic knot according to its
quality...
prev parent reply other threads:[~2018-05-13 7:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-27 21:08 bug#31290: Fundamental bugs in syntax-propertize Alan Mackenzie
2018-05-08 12:35 ` Dmitry Gutov
2018-05-12 11:26 ` Alan Mackenzie
2018-05-13 7:33 ` Andreas Röhler [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=79bd61c9-1d9c-d2f4-9206-3623a0553ff1@easy-emacs.de \
--to=andreas.roehler@easy-emacs.de \
--cc=31290@debbugs.gnu.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.