Re: forward-comment and syntax-ppss

[Dmitry Gutov]

On 17.12.2016 17:38, Stefan Monnier wrote:

> This said, another option is to declare that such are misuses of
> narrowing (like Lars suggests) and then use some other way to indicate
> which "buffer start" position to use in syntax-ppss.  As a matter of
> fact that's consistent with what I advocated back in the
> "indentation-context" discussion (and was then implemented and later
> removed).

That removal's on me, at least in part. So if we don't agree on an 
alternative approach, I'd post a patch to bring prog-widen (better name 
wanted?) back.

That said, it won't solve everything.

1. Minor thing: if we wanted to use it for Info, it would probably need 
a more neutral name, not prog- suffix.

2. Using prog-widen in syntax-ppss is by itself equivalent to using a 
syntax-ppss-dont-widen variable, which Alan doesn't like, in that 
point-min cache management is left up to the caller. Do you like that 
approach, or prefer a more opaque cache invalidation implemented inside 
syntax-ppss?

All that aside, here's an approach that I feel hasn't been given due 
attention in previous discussions: why don't we push all widen calls up 
the call stack?

- Prohibit font-lock-keywords from widening. 
font-lock-default-fontify-region already widens when needed. CC Mode is 
the only violator I know of, but we can probably ignore it either way 
because it would raise errors otherwise.

- Prohibit indent-line-function's from widening. Do that instead in 
indent-for-tab-command.

- Likewise for M-x imenu and any similar facilities. Keep widening to 
the commands, or some high level code that is not major mode-specific. 
font-lock-default-fontify-region is a counter-example of sorts, but it 
works for mmm-mode because of font-lock-dont-widen.

All these are hard to verify for arbitrary code, but we'd have these 
rules as a "Mixed-mode major modes" guidelines, and could make sure they 
are followed in the built-in modes. Most of them, at least.