I'm not quite sure what you're saying here. Normally, a piece of
software not working properly is an extremely strong argument against it
(though it's an equally strong argument for fixing it).
It's probably a strong argument against installing it willy nilly, yes.
What, exactly, is this patch intended to do? That's not obvious.
It gets rid of some pathological cases where backward scanning currently
may re-scan the whole buffer over and over again, each time from
point-min, resulting in excruciatingly slow backward movement (these
cases are fairly rare, luckily).
I think this would be a last resort, when nothing else can work. The
syntactic primitives should not have high level lisp code poking about
in their innards.
I don't much care for such philosophy, because I consider syntax-ppss to
be low-level Lisp code.
When it comes to narrowing a buffer, I think that the syntactic
context of a buffer position should not depend on whether the buffer
has been narrowed.
As you know by now this is just one opinion, and other users of
narrow-to-region beg to differ, and hence we will need to provide a way
for users of narrow-to-region to communicate their intentions, since
without that extra information, there can be no reliable caching of
parsing.
If there are use cases this inconveniences, I think that those use
cases' use of narrowing is mistaken, and some other tool should be
used in its place.
Fine by me.
So I see this patch as an opportunity to improve syntax-ppss.
I don't think anybody will object to improving syntax-ppss. But, at the
same time, calling syntax-ppss from the C syntax routines should be
avoided, as far as possible. Such calls are likely to transform
side-effect free functions (such as forward-comment) into side-effect
encumbered functions, which is likely to make them less useful, and to
make Emacs more buggy, less flexible and more difficult to use.
We've happily crossed that bridge already (tho not by calling
syntax-ppss but by calling syntax-propertize).
And, just to emphasise, I think it's clear that syntax-ppss has no
business in forward-comment. syntax-ppss is slow (compared to the
current implementation of forward-comment),
The patch I showed only uses syntax-ppss when we would otherwise
re-parse the whole buffer, so it shouldn't slow things down too much.
BTW, when writing syntax-ppss I did not really intend to "speed things
up", but to get rid of pathologically slow behavior. In many cases
calling parse-partial-sexp from point-min will be faster than calling
syntax-ppss (mostly because syntax-ppss is all written in Elisp, so just
the time to consult its cache can be longer than the time to compute the
answer from scratch), but its behavior should stay "good enough" in
a longish buffers (where calling parse-partial-sexp from point-min
becomes excessive).
IOW, syntax-ppss will be slower than parse-partial-sexp when
parse-partial-sexp is fast, but it will be faster when
parse-partial-sexp is slow.
and there's no need for it, given the existence of the
comment-cache branch.
This branch has fundamentally the same caching problems as syntax-ppss
(i.e. in case of narrowing it may sometimes return what the user
intended and sometimes not), unsurprisingly. And it also suffers from
"Such calls are likely to transform side-effect free functions (such as
forward-comment) into side-effect encumbered functions".
And of course, it's a much larger change, with a redundant cache.
So, from where I sit I'd put it the other way around:
"there's no need for the comment-cache branch, given the existence of
this syntax-ppss-based simple patch".
Of course, you could argue that your patch works with cc-mode whereas
mine might not. It's no surprise, since you actually changed cc-mode
to accommodate your comment-cache, like you could do to accommodate
this patch.
Stefan