Re: forward-comment and syntax-ppss

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

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

What is your understanding of "narrowing"?  In my book, what it means is
"make the text outside of the region inaccessible".  So why should
syntax-ppss be granted an exception (note: I don't disagree that it can
make sense to grant an exception for it, but that granting it an
exception only makes sense based on some expected usage context of
narrowing, i.e. based on the intention behind its use).

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

Let's take sm-c-mode as an example: it marks CPP preprocessor elements
as being comments.  Yet, it also wants to know if there are strings
inside that "comment", so it narrows to the "comment" and then
parses the result as a chunk of C code.
[ Whether this approach is good or bad is beside the point: this
  is just an example of narrowing, where the context should not affect
  what is considered "inside a string" or not.  ]

Other examples come from the context of
multiple-major-modes-in-a-buffer.

Yet others come from the use of narrowing in things like Info-mode and
Rmail (where a large buffer contains many "pages" and that's an
implementation detail: the user only cares about the pages and not
whether they're kept in a single buffer/file or not).

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

Could be.  Then again, maybe not.  After all, you're saying that the
only "meaningful" use is when the scan starts at 1, so the overwhelming
majority of uses should be in a widened buffer (or are errors that need
to be fixed).

Only experimentation could say that.  But FWIW, my gut feeling agrees
with yours.

>> - index the cache with point-min.
> I don't understand what you mean by this.

The cache is currently (conceptually) a function which takes a buffer
position and returns to you an earlier position, along with the state at
that position.

Change this so that the function takes additionally `point-min` as
argument, so it can keep different states for the same positions,
depending on the `point-min` that was used to compute that state.

Or more concretely, replace `syntax-ppss-cache` with (assq (point-min)
syntax-ppss-cache-alist).

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

Together with the existing implementation of syntax-ppss, it's very
unlikely to work reliably.

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

I think that any such breakage could be reproduced with the current
implementation of syntax-ppss, which would mean that the problem is not
a new problem introduced by the "different" function.

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

I consider the behavior of syntax-ppss when point-min!=1 to be
currently undefined (and indeed, it's unreliable).

So what we're discussing is how to refine/augment/improve the behavior,
rather than introducing a brand new behavior.


        Stefan