Re: forward-comment and syntax-ppss

[Stefan Monnier]

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

Then I misunderstood.  What is the problem that your proposal aims to fix?

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

But if we have something like syntax-ppss-parse-start, why not use that
same info more generally when some function wants to widen (e.g. make
it also replace font-lock-dont-widen)?

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

But the problem is the linkage between the narrowing and the widening,
not between the user-command and the widening.

In general, the command currently executed does not know who put the
narrowing nor why, so it still doesn't know what's the intention behind
it, and hence can't decide whether to widen or not, nor or much to widen.

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

Not sure which problem you're referring to.  Do you mean that when
syntax-ppss-parse-start is changed, syntax-ppss is not warned?

> haven't commented on syntax-ppss's cache management ideas.

Not sure on which part you want my input.  I can't remember all that's
been suggested, so here's just some random opinions of mine on the
subject:
- 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.

- 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, and it should probably be modified via functions
  (rather than directly via setq), so that those functions can flush the
  syntax-ppss cache when needed.  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).

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

Not necessarily, no.

> I'm saying that's unnecessary, and that indent-for-tab-command can do all
> the widening itself.

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.

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

Sure.  I think the current discussion is about "what should
prog-widen/syntax-ppss-parse-start look like" more than "who/when should
we call prog-widen".

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

If by "current proposal" you mean to prog-widen in
indent-according-to-mode, then I agree it's a good idea.


        Stefan