[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#23019: parse-partial-sexp doesn't output the full state needed for i
bug#23019: parse-partial-sexp doesn't output the full state needed for its continuance.
Mon, 04 Apr 2016 08:15:52 -0400
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)
>> 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,
> 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
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.