Re: CC Mode in MMM Mode(s). [Was: Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls]

[Dmitry Gutov <dgutov@yandex.ru>]

On 12/5/17 9:01 PM, Alan Mackenzie wrote:

> As a first approximation, dealing with CC Mode's need to widen might
> help.  (I don't yet know how that will work for when several CC Mode
> chunks are embedded in a single main buffer (?local variables), but that
> should become clearer as time goes by.)

As far as I'm conncerned, CC Mode can consider every chunk a separate 
buffer. It might be suboptimal for some features, but let's take one 
step at a time.

> In my quick skim of MMM Mode's code, I didn't see any way of accessing
> all the various pertinent "point-min"s: there's the point-min set by the
> user, the point-min set by MMM Mode to restrict operations to the
> current chunk, and there's the point-min set by (e.g.) CC Mode for its
> own purposes.  The same applies (perhaps a bit less so) to all the
> "point-max"es.

You use the current restriction as set when indent-line-function is 
called. Or font-lock-keywords are applied. You can stash those point-min 
and point-max dynamically for your convenience, too.

> Wasn't `prog-widen' supposed to get the MMM Mode's chunk boundaries?

Kind of. It only returned those boundaries when inside 
indent-line-function, too.

> What are the recognised ways in MMM Mode of getting these three pairs of
> (point-min point-max)?

For the ones "set by MMM Mode", you can call point-min and point-max at 
the beginning of indent-line-function. Again, you can stash it for later.

Of restrictions set by CC Mode I know nothing about.

And as for point-min set by the user, why do you want to know? 
indent-for-tab-command should have taken care of widening by that time.

>> If you manage to do it at all, that would be an achievement. But just
>> figuring out the biggest problems should help us to design the feature.
> 
> I'm thinking about first adapting all the various CC Mode caches which
> implicitly or explicitly start at 1, each to have a "cache-min" position
> which would coincide with the chunk-start.

That sounds like a plan. Maybe also avoid using some of the caches when 
the length of a chunk is smaller than a predefined value.

> Maybe I could use some
> mechanism to avoid invalidating them when a buffer change before the CC
> Mode chunk changes this "cache-min" position.

The overhead of such solution would probably be N(number of chunks), 
wouldn't it?

> Ah, Cyprus!  I'll bet it's a deal warmer than Germany at the moment!

Indeed. About 15 degrees warmer. :-)