[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 04:31:28 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Thunderbird/50.0

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

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.

reply via email to

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