Re: forward-comment and syntax-ppss

[Alan Mackenzie]

Hello, Stefan.

On Thu, Dec 08, 2016 at 04:13:04PM -0500, Stefan Monnier wrote:
> >> 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.

Indeed.

> 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.

Thanks for the explanation for leaving it unfixed, which I understand
and accept.  Why don't you chose both (i.e. two distinct functions)?  :-)

> >> 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).

OK, maybe.  I'm struggling a bit with your analogies.  But I think I see
what you're trying to say.

> 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"?

Yes.  It certainly doesn't fail in anything like the fashion that
syntax-ppss does.  Modulo any remaining bugs.

> > 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.

No.  It makes sense, full stop.  If it doesn't, then the notion of
narrowing doesn't make sense either.  Plainly it does.  The definition
of a primitive cannot be dependent upon the psychology of the hacker
using it.

There is nothing in the notion of narrowing which suggests that it
should change the syntactic context of any text - if a certain buffer
position is inside a string, it is inside the string; it doesn't
suddenly become outside the string by virtue of where the buffer is
narrowed.  Were that not the case, the notion "inside a string" would
become meaningless.

> > 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 if point-min is different from last time.

Likely, the cache would be flushed so much it wouldn't really serve much
purpose.

> - index the cache with point-min.

I don't understand what you mean by this.

> I'm sure you too can come up with other solutions.

Maybe I could.

> 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.

You would then have a different function.  Something I've been
suggesting for a long while.

> 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.

No, that code is not broken.  It is syntax-ppss that is broken.  If you
replace syntax-ppss with a different function (as I have been
advocating), that is going to break some code which uses syntax-ppss.

> > 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"?

Because we're talking about a different function which does a job
different from what syntax-ppss is specified to do.  That is not a minor
change, regardless of how few lines of code and documentation need to be
changed.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).