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

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> I'd like to hear what John thinks about the idea of re-using "nth 5" instead
>> of adding a new entry, but other than that, I think it's OK to commit,
>> thanks.
> How long has this stuff been out in the field?

Many many years.

> Do you think it's well known enough that anyone is depending on the
> earlier behavior of the nth 5 value?

There are definitely packages which use the (nth 5 ..) value returned
from parse-partial-sexp.  E.g. cperl-mode does:

			    state (parse-partial-sexp pre-B p))
		      (or (nth 3 state)
			  (nth 4 state)
			  (nth 5 state)
			  (error "`%s' inside `%s' BLOCK" A if-string))
as well as

	     (let ((pps (parse-partial-sexp (point) found)))
	       (or (nth 3 pps) (nth 4 pps) (nth 5 pps)))))

and verilog-mode does:

		 (setq state (parse-partial-sexp (point) end-mod-point 0 t nil))
		 (or (> (car state) 0)	; in parens
		     (nth 5 state)		; comment
		     ))

sh-script also uses it, along with perl-mode.

> I have a feeling it's OK to re-use it.

That's also my feeling.  All the uses I've found would be unaffected
(e.g. because they're in modes where there are no 2-char comment
markers, so there is really no change in behavior; or because it's only
used at positions which can't be in the middle of a 2-char comment
marker).
It's a "natural extension" of the previous meaning of "nth 5".

But admittedly, it's hard/impossible to find all uses, so I can't claim
with confidence that it won't break some code somewhere.


        Stefan