Re: CC Mode in MMM Mode(s).

[Dmitry Gutov <dgutov@yandex.ru>]

On 12/6/17 8:19 PM, Alan Mackenzie wrote:

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

Pretty much. With the exception that overlays can nest, and so hunk can 
be only a part of an overlay.

For font-lock, that is (because it's usually the least 
context-dependent, so that seems the least error-prone).

For indentation, however, we might narrow to the bounds of the current 
overlay, even if there are some nested ones inside it. We don't actually 
do that in the general case (random combination of modes), though. I've 
only really worked on custom indentation for html-erb-mode (defined in 
mmm-erb.el).

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

It doesn't. For beginning-of-defun, it should likewise define its own 
beginning-of-defun-function which narrows and delegates (like usual), 
but that never actually came up in user requests so far.

The other, non-customizable commands (for example major mode specific 
ones) work on best effort basis. It's not an exact science. :-)

More importantly, mmm-mode also applies font-lock-keywords also by 
narrowing, like mentioned above. IIRC, some code called in 
font-lock-keywords in CC Mode widens, so that would have to be taken 
care of. And it's even more important than indentation, I'd say.

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

That's, um, why? Sounds like a very niche optimization.

Still, that cache might also be keyed on point-min, can't it?

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

I... don't really want to do that, but we might add that to the next 
version of the multi-mode API. Can you do without it in the meantime?

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

It might not be helpful at all anyway. syntax-ppss derives some benefit 
from it, but that's because parse-partial-sexp is faster than running a 
bunch of Lisp code, for smaller chunks of text.

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

Tradeoffs. I've worked on files with *lots* of Ruby chunks, but the 
situations where CC Mode will be used for inner chunks might be 
sufficiently different that it becomes less of a problem.

Another approach might be to put the caches into chunk-local variables, 
but I'm not sure if we handle before/after-change-function correctly 
when a change crosses chunk boundaries. Not sure how to implement this 
properly either.

Anyway, I'd devote as little time as possible to performance 
optimization right now, and see if we can get it working at all.