Re: CC Mode in MMM Mode(s).

[Alan Mackenzie <acm@muc.de>]

Hello, Dmitry.

On Wed, Dec 06, 2017 at 01:34:40 +0200, Dmitry Gutov wrote:
> 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.

I think I now understand.  Each chunk is a separate overlay, and each
overlay maintains its own list of local variables.

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

As a matter of interest, how does MMM mode handle its chunks for
commands which aren't indentation (such as beginning-of-defun)?

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

OK.

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

Because CC Mode's "state cache" (bad name, I know), which records open
parens/braces/brackets preceding point, records those things only in the
accessible portion of the buffer.  If that portion started within a CC
Mode chunk, things might/would go wrong if adjustments weren't made.

> indent-for-tab-command should have taken care of widening by that time.

Perhaps a function to return (user-point-min . user-point-max) might be
useful.

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

That's an idea, but it would add (a little) complexity.

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

Yes.  But it would be less than the overhead of recalculating the caches
after a buffer change within the CC Mode chunk, since it would just need
to add a constant offset onto each buffer position in the caches.

-- 
Alan Mackenzie (Nuremberg, Germany).