[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Musings: Supposed places of safety, guaranteed by parse-partial-sexp
From: |
Alan Mackenzie |
Subject: |
Re: Musings: Supposed places of safety, guaranteed by parse-partial-sexp are not safe. |
Date: |
Tue, 6 Dec 2011 10:33:11 +0000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Hello, Martin.
On Tue, Dec 06, 2011 at 11:15:22AM +0100, martin rudalics wrote:
> > The parse-partial scanner works strictly left to right. If (nth 5
> > ppss) records the left hand bit of "/*", we are not yet in a
> > comment. We're probably about to do a division. Similarly, after *
> > of "*/", we're still in the comment, probably just passed a comment
> > prefix.
> If we can look ahead by one character, there is no probability but
> certainty. And the latter is what you want in (nth 4 ppss). The
> remaining case is with an "/" at the end of a buffer and that case
> wouldn't trouble me.
One can delete anything inside a comment and it is still a comment. We
(i.e. I :-) don't want to introduce an extra special case about the first
character of a comment.
> > I disagree. I think keeping the stricly L to R invariant of the
> > parse is critically important (but don't ask me why :-).
> Why would looking ahead violate a L to R rule?
Think of it as the direction one's head is turned on a British street
when about to cross it suicidally. At the moment, parse-partial-sexp
looks only at the characters to the left; it never pays any attention
whatsoever to characters on the right.
p-p-s is a finite state machine. If it starts looking to the right, it
will still be a fsm, but with many more states.
Again, what of "/*/" mentioned by Stefan? If we're already in the
comment after the first "/", then we're apparently looking at a comment
ender. This complication (and it is complicated) surely condemns the
approach.
I think we should use the same approach as for escape characters: record
the fact in (nth 5 state) that we've passed one, but otherwise take no
action.
> martin
--
Alan Mackenzie (Nuremberg, Germany).
- Re: Musings: Supposed places of safety, guaranteed by parse-partial-sexp are not safe., (continued)
- Re: Musings: Supposed places of safety, guaranteed by parse-partial-sexp are not safe., martin rudalics, 2011/12/04
- Re: Musings: Supposed places of safety, guaranteed by parse-partial-sexp are not safe., Stefan Monnier, 2011/12/04
- Re: Musings: Supposed places of safety, guaranteed by parse-partial-sexp are not safe., martin rudalics, 2011/12/04
- Re: Musings: Supposed places of safety, guaranteed by parse-partial-sexp are not safe., Andreas Röhler, 2011/12/04
- Re: Musings: Supposed places of safety, guaranteed by parse-partial-sexp are not safe., Stefan Monnier, 2011/12/04
- Re: Musings: Supposed places of safety, guaranteed by parse-partial-sexp are not safe., martin rudalics, 2011/12/05
- Re: Musings: Supposed places of safety, guaranteed by parse-partial-sexp are not safe., Stefan Monnier, 2011/12/05
- Re: Musings: Supposed places of safety, guaranteed by parse-partial-sexp are not safe., Alan Mackenzie, 2011/12/05
- Re: Musings: Supposed places of safety, guaranteed by parse-partial-sexp are not safe., Alan Mackenzie, 2011/12/05
- Re: Musings: Supposed places of safety, guaranteed by parse-partial-sexp are not safe., martin rudalics, 2011/12/06
- Re: Musings: Supposed places of safety, guaranteed by parse-partial-sexp are not safe.,
Alan Mackenzie <=
- Re: Musings: Supposed places of safety, guaranteed by parse-partial-sexp are not safe., martin rudalics, 2011/12/06
- Re: Musings: Supposed places of safety, guaranteed by parse-partial-sexp are not safe., Stefan Monnier, 2011/12/06