Re: forward-comment and syntax-ppss

[Alan Mackenzie]

Hello, Dmitry.

On Thu, Dec 08, 2016 at 11:24:12PM +0200, Dmitry Gutov wrote:
> On 08.12.2016 22:15, Alan Mackenzie wrote:

> > I propose, additionally, a new buffer local variable which, if
> > non-nil, will contain a buffer position to use in place of the "1".

> That's functionally equivalent to my proposed patch with
> syntax-ppss-dont-widen, except for the case where that buffer local
> value turns out to be higher than POS.

That could be.  But a variable called wyntax-ppss-dont-widen has the
caller explicitly messing around with the flowchart of syntax-ppss,
which is not a good thing.  I think my proposed new local variable is
better for this reason.

> Can parse-partial-sexp parse backwards?

No, not at all, and it's unlikely ever to be able to do so.

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

> All the primitives you've enumerated above work on simple values and 
> don't change the buffer state.

Narrowing doesn't change the buffer state either, beyond what it
explicitly says it does.  In particular, it doesn't change things like
whether a particular buffer position is inside a string.

> Narrowing is anything but austere.

I disagree.  I think there are attempts afoot to make it non-austere,
and that these attempts are mistaken in principle.

> > Complexifying narrowing by introducing a notion of "intention" would
> > surely make it more difficult to use and possibly foul things up
> > massively.

> The reasons for it have been described plenty of times. And no, it will 
> be pretty trivial conceptually.

It tends to be trivial to add stuff on.  Much easier than getting rid of
stuff.  And that extra stuff might well be fat rather than muscle.

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

> You keep repeating that word (replace), as though that solves anything.

It would solve bug #22983.

> If we introduce the new function and all of Emacs core switches to it, 
> and that function doesn't have an "escape hatch", the multi-mode 
> packages will be hung out to dry.

I wouldn't want that to happen.  Does the suggested new buffer local
variable (to specify the lower bound in the notional partial-parse-sexp)
not provide this escape hatch?

-- 
Alan Mackenzie (Nuremberg, Germany).