bug#23019: parse-partial-sexp doesn't output the full state needed for its continuance.

["Andreas Röhler" <andreas.roehler@easy-emacs.de>]

On 15.03.2016 11:15, Alan Mackenzie wrote:
> Hello, Andreas.
>
> On Tue, Mar 15, 2016 at 10:35:08AM +0100, Andreas Röhler wrote:
>
>
>> On 15.03.2016 10:13, Alan Mackenzie wrote:
>>> Hello, Emacs.
>>> When parse-partial-sexp finishes a parse, it fails to record whether or
>>> not its end point is just after the first character of a two character
>>> comment starter or ender.  When the resulting state is used as an
>>> argument to resume the parse, p-p-s will be unaware that the comment has
>>> started or ended and produce false results.
>>> Proposed solution: Add an extra element to the parser state, recording the
>>> syntax of the last character passed over before the end of the parse.
>>> This would be used by parse-partial-sexp to initialise its parse.
>>> Also: the existing element 9 (the list of currently open parens) and the
>>> new element should be explicitly documented in the Elisp manual, together
>>> with a statement that there may be further elements in the parse state
>>> used internally by parse-partial-sexp (for future expansion).
>
>> a comment start might be composed not just by two characters, but by
>> three or more. What then?
> We'd have to start thinking about extending parse-partial-sexp, or
> invent some workaround.  Maybe.  There must be some languages (?html)
> where this is the case.  What is done in these?

May you send me this (or more) example use-cases? Couldn't find the one 
already given, sorry.

Addressed this issue in my generic beg-end.el

https://github.com/andreas-roehler/werkstatt/blob/master/subroutines/beg-end.el

In case beg-end forms used a start-string, look if the char-at-point 
would match this string.
Then look if the char-before is before in string, etc.