Re: forward-comment and syntax-ppss

[Stefan Monnier]

> It can track the value of point-min, but it won't really know what to do
> with the caches corresponding to the previous point-min values.

I'd expect they'd get flushed by syntax-ppss-flush-cache.

But I don't really see why you think there's a problem to solve there.
I assume syntax-ppss would usually "widen to syntax-start-pos" or
somesuch, so there should not be many different point-mins indexed there.

>> - we could/should have a macro (with-new-syntax-ppss-context
>> ... &rest BODY) which runs BODY such that calls to syntax-ppss in
>> there can be cached within this scope but don't use the outer
>> syntax-ppss cache and don't affect it.  This could be used when
>> a command wants to temporarily use an ad-hoc syntax-table (typically
>> using with-syntax-table), for example.  It should probably be made to
>> obey the current narrowing limits, since such uses often additionally
>> want to restrict the parsing to a subpart of the buffer.
> That seems sound. And, basically, all that's necessary for mixed-mode
> packages to work.

But the multi-mode case would additionally want to preserve the "inner
cache" across uses of with-new-syntax-ppss-context.

>> - if we introduce a syntax-ppss-parse-start, it should not have `ppss`
>> in its name, it should probably try to include some of the design of
>> indentation-context,
> Which ones? Having both lower and upper bound?

My memory is too fuzzy about that to have a clear opinion.

> It's not indentation specific, so using the name is out of the
> question, I think.

I wasn't thinking about re-using the name, no.

>> This said, if needed it'd probably be OK to have syntax-ppss
>> auto-detect changes instead (after all, syntax-ppss is still
>> implemented in Elisp, so there is a lot of room for speed up).
> It might not we the fastest, but I'd like it to be algorithmically sound.

Detecting changes is algorithmically cheap.

>> I wouldn't do it in indent-for-tab-command, but I agree that it should
>> be done in indent-according-to-mode rather than forcing every major
>> mode's indentation function to widen.
> Shouldn't indent-for-tab-command call indent-according-to-mode, then?

Doesn't it?  Oh wait, it technically doesn't because it wants to handle
the `no-indent` return value of `indent-line-function` differently.

But conceptually, I still consider it a call to indent-according-to-mode ;-)

> Yes, and also agree about a similar rule for font-lock-keywords.

That's already the case, no?

> I really meant widen, though. Not sure what calling prog-widen in there
> would mean, semantically, because according to the previous discussion
> prog-narrowing was something a mixed-mode code would institute. But it's
> down the call stack from indent-according-to-mode (via a mixed-mode aware
> indent-line-function), not above it.

Indeed, but I meant "somewhere between a call to
indent-according-to-mode and the call to major-mode specific
indent-line-function".

The point is that the indent-line-function should not need to widen,
although maybe the buffer is not fully widened (depending on whether
the multi-mode system uses narrowing, maybe).


        Stefan