[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: forward-comment and syntax-ppss

From: Dmitry Gutov
Subject: Re: forward-comment and syntax-ppss
Date: Mon, 19 Dec 2016 15:34:17 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Thunderbird/50.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]