emacs-devel
[Top][All Lists]
Advanced

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

Re: CC Mode in MMM Mode(s).


From: Dmitry Gutov
Subject: Re: CC Mode in MMM Mode(s).
Date: Thu, 7 Dec 2017 02:21:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Thunderbird/58.0

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.



reply via email to

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