From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: 23019@debbugs.gnu.org
Subject: bug#23019: parse-partial-sexp doesn't output the full state needed for its continuance.
Date: Fri, 18 Mar 2016 15:11:55 +0000 [thread overview]
Message-ID: <20160318151154.GA9433@acm.fritz.box> (raw)
In-Reply-To: <jwvmvpwcsn1.fsf-monnier+emacsbugs@gnu.org>
Hello, Stefan.
On Fri, Mar 18, 2016 at 12:49:07AM -0400, Stefan Monnier wrote:
> > Do this by adding two new fields to the parser state: the syntax of the last
> > character scanned, and the last end of comment scanned. This should make the
> > parser state complete.
> Thanks. I like the "syntax of the last character scanned", but I don't
> understand the reasoning behind "last end of comment scanned". Why is
> this relevant? Is it in case the "last character scanned" was a "slash
> ending a comment" so as to avoid treating "*/*" as both a comment closer and
> a subsequent opener?
That's exactly the reason.
> If so, I'm not sure I like it.
I don't really like it either.
> It sounds to me like there's a chance it's actually incomplete (e.g.
> it doesn't address the similar problem when the "last character
> scanned" is an end of a string which also happens to be a valid
> first-char of a comment-starter), and even if it isn't, it "feels
> ad-hoc" to me.
Now even I wouldn't have come up with that end-of-string scenario. ;-)
Such a scenario is presumably one reason why, in scan_sexps_forward, two
character comment delimiters are handled before strings.
> Would it be difficult to do the following instead:
> - get rid of element 11.
Done.
> - change element 10 so it's nil if the last char was an "end of
> something". Another way to look at it, is that the element 10 should
> only be non-nil if the "next lexeme" might start on that
> previous character.
I've tried this, and it's somewhat ugly. Setting the "previous_syntax"
to nil is also needed for the asterisk in "/*". The nil would appear to
mean "the syntactic value of the last character has already been used
up". So the "previous_syntax" is nil in the most interesting cases. It
also feels somewhat ad-hoc.
How about this idea: element 10 will record the syntax of the previous
character ONLY when it is potentially the first character of a two
character comment delimiter, otherwise it'll be nil. At least that's
being honest about what the thing's being used for.
> I also have a side question: IIUC your patch makes the 5th element
> redundant (can be replaced with a test whether "last char syntax" was
> "escape"), is that right?
It would appear to be, yes. We really can't get rid of element 5,
though, because there will surely be code out there that uses it. But
if I change element 10 as outlined above, element 5 will no longer be
redundant.
> Stefan
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2016-03-18 15:11 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-15 9:13 bug#23019: parse-partial-sexp doesn't output the full state needed for its continuance Alan Mackenzie
2016-03-15 9:35 ` Andreas Röhler
2016-03-15 10:15 ` Alan Mackenzie
2016-03-15 13:38 ` Andreas Röhler
2016-03-17 12:58 ` Stefan Monnier
2016-03-17 21:49 ` Alan Mackenzie
2016-03-18 4:49 ` Stefan Monnier
2016-03-18 15:11 ` Alan Mackenzie [this message]
2016-03-18 15:22 ` Alan Mackenzie
2016-03-18 16:23 ` Stefan Monnier
2016-03-18 18:25 ` Alan Mackenzie
2016-03-18 19:36 ` Stefan Monnier
2016-03-19 17:06 ` Alan Mackenzie
2016-03-20 1:30 ` Stefan Monnier
2016-03-20 13:41 ` Alan Mackenzie
2016-04-03 22:53 ` John Wiegley
2016-04-04 12:15 ` Stefan Monnier
2016-04-05 12:54 ` Alan Mackenzie
2016-04-05 13:50 ` Stefan Monnier
2016-04-05 14:44 ` Alan Mackenzie
2016-03-18 16:27 ` Stefan Monnier
2016-03-18 19:16 ` Alan Mackenzie
2016-03-18 19:40 ` Stefan Monnier
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=20160318151154.GA9433@acm.fritz.box \
--to=acm@muc.de \
--cc=23019@debbugs.gnu.org \
--cc=monnier@IRO.UMontreal.CA \
/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).