Re: forward-comment and syntax-ppss

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

>> And how would the new function not face the same breakage that can't be
>> fixed?
> It would have a sensible definition.  "Returns the equivalent of
> (parse-partial-sexp (point-min) POS)" is a silly definition which cannot
> be coded up in any reasonable fashion.

Oh, it can be coded alright if we want it (it's not terribly hard,
actually).  The choice was largely arbitrary and indeed the behavior is
currently an unreliable mix of point-min and 1.

Changing syntax-ppss to reliably return (parse-partial-sexp (point-min) POS)
or (parse-partial-sexp 1 POS), is not terribly hard.  The issue is
mostly one of choosing between the two, where some cases want one and
others want the other, which is why so far I haven't actually decided
and left it simply unreliable when used in a narrowed buffer.

>> As you should know, your comment-cache code suffers from the exact same
>> problem.
> Rubbish.  Modulo any remaining bugs, it does what it says it does.

Without your cache, the behavior of forward-comment is consistent with
a semantics like (parse-partial-sexp (point-min) POS), whereas with your
cache, forward-comment suddenly gets a new semantics similar to
(parse-partial-sexp 1 POS).

I don't claim the new behavior is worse, but it will introduce breakage
in some existing code (just like my syntax-ppss patch, of course, for
the same reasons).  So does it "[do] what it says it does"?

> Nor should it.  Our primitives `car', `cdr', `list', etc. also don't say
> what the intention behind them is; they just work.  Narrowing is what it
> is.  Simple and austere.   Complexifying narrowing by introducing a
> notion of "intention" would surely make it more difficult to use and
> possibly foul things up massively.

Yet, you want to use (parse-partial-sexp 1 POS), which only makes sense
if you treat narrowing as having a particular intention.

> Rubbish again.  "Returns the equivalent of (parse-partial-sexp
> (point-min) POS)" cannot be implemented in any reasonable fashion,

Of course it can.  Here are two easy options:
- flush the cache is point-min is different from last time.
- index the cache with point-min.
I'm sure you too can come up with other solutions.

This is a non-issue.  The real issue is to decide which behavior to get when.

> and just putting a `widen' into the current code won't change that
> one bit.

It would change the behavior to (parse-partial-sexp 1 POS) so of course,
the doc would be changed accordingly.  Currently any code which relies
on syntax-ppss returning (parse-partial-sexp (point-min) POS) when
narrowed is broken anyway, so we can easily make such a change.

> As I said above, I think syntax-ppss should be retired and replaced by a
> function which does parse-partial-sexp starting at 1 rather than
> (point-min).

We're talking about changing 3 lines of doc and 2 lines of code.
Why would you describe such a trivial change as "retire and replace"?


        Stefan