Alan Mackenzie <acm@muc.de> writes:
>
> (i) The new function `check_comment_start' doesn't have a comment saying
> what its return value means.  Possibly you could instead rename it so
> that the name implies what it returns.  Maybe something like
> `in_double_comment_opener'.

Good point, I've updated the patch.

>
> I'll admit I haven't actually tried out the code, mainly because you've
> written a test file.

Oh dear, maybe I should have withheld the test file ;)

>
> (ii) In `parse-partial-sexp-continue-over-comment-marker', variable aftC
> is the position in the middle of the comment closer "*/".  I don't think
> you are testing in any way that element 10 (nil, or the syntax of the
> position just before the end point when that position might be the first
> character of a two-character construct, i.e. an escape or first char of a
> double-char comment delimiter) is correct.

My idea was that its effect would be tested by using pps-preC as
OLDSTATE, which avoids having to encode the specifics in the test.  I
added another clause which uses pps-aftC to cover parsing from the
middle of a comment closer as well as opener.