Re: forward-comment and syntax-ppss

[Dmitry Gutov]

On 19.12.2016 15:12, Stefan Monnier wrote:

> But that means any command which somewhere internally uses syntax-ppss
> would need to widen?  So any change which introduces a new call to
> syntax-ppss would imply revising all callers of this code and all
> callers of those callers (etc...) to make sure they widen?

No, syntax-ppss would probably be an exception, and call `widen' itself, 
as well as include a syntax-ppss-dont-widen variable, or 
syntax-ppss-parse-start, like proposed by Alan.

This seems necessary to have a stable syntax cache, e.g. to have it as a 
basis of comments navigation.

> What if they don't want to widen because they're commands which *should*
> limit themselves to the narrowed region?

I see no big obstacles to that, so far.

> That seems to presume that narrowing is only used for multi-mode kind of
> contexts, which currently is the exception rather than the rule.

The idea is to preserve its usability for both cases, by moving the 
choice when to narrow or widen up the stack, closer to the commands that 
the user invokes (if indeed the code is called interactively), because 
they are likely to be more aware of the user's intent.

> I think the core of the problem is the use of narrowing for widely
> different purposes, so indeed we should decide that some of those uses
> are simply inappropriate and provided something else for those uses.

That's one option. But again, prog-widen doesn't solve everything, and 
you haven't commented on syntax-ppss's cache management ideas.

> But I think the case "user-level narrow for Q&R" is hard to replace
> reliably, so I'd rather keep narrowing for *that* purpose, and try to
> introduce something else for the other uses (e.g. for multi-mode).

You're saying that python-indent-line and its callees should call 
prog-widen, right?

I'm saying that's unnecessary, and that indent-for-tab-command can do 
all the widening itself. Same for font-lock. And that takes care of the 
two known obstacles in the mixed-major-mode space, with very little code 
or changes to the API.

Even if we add "something else", upon deciding that it's really needed, 
later, the current proposal shouldn't hurt.