Re: eLisp fontlock with mmm-mode

[Alan Mackenzie]

Joe Kelsey <joe-gg@zircon.seattle.wa.us> wrote on 5 Sep 2003 08:02:02
-0700:
> Kevin Rodgers <ihs_4664@yahoo.com> wrote in message
> news:<3F561EAE.3030506@yahoo.com>...
>> Joe Kelsey wrote:

>> > Aside from that, support for mixed-mode buffers suffers in Emacs due
>> > to limitations on the ability of using syntax tables for multiple
>> > purposes in a buffer.   The design of syntax tables implies that a
>> > single syntax table controls an entire buffer in a single style.
>> > mmm-mode attempts to get around this by "dynamically" switching
>> > syntax tables as the point moves through various areas of a buffer.
>> > One very noticable side effect involves the fact that when you set
>> > up the syntax table for a particular sub-buffer, it changes the
>> > entire buffer view.  Until someone comes up with a way to
>> > regionalize syntax tables, you just have to live with the "bleeding"
>> > of syntax table-based font-locks between buffer regions.

>> I thought that had already been done; from the Special Properties node
>> of the Emacs Lisp manual:

> Text properties apply to portions of the buffer and constitute the
> basis of font-lock mode.  The interaction between the global
> syntax-table and text properties allow font-lock to operate in a
> specific buffer.

> mmm-mode works by segregating the buffer into overlay sections.  As
> the cursor moves outof one overlay and into another, it switches the
> global syntax-table.

> The syntax-table text property works differently from the global
> syntax table in that it applies to a specific section of the buffer. 
> However, applying a syntax-table property to a specific section of
> text also involves a lot of extra overhead and thus it doesn't come
> cheaply.

Joe, I take it the value you are giving to the syntax-table text property
is a syntax-table, and you're giving this to the whole mmm section of the
buffer in a single operation.  What do you mean by "a lot of extra
overhead"?  Do you mean extra coding or sluggish performance?  If the
latter, do you have any quantitative feel for how bad the hit is?

> I have experimented in mmm-mode with using the syntax-table text
> property to make inactive overlays have specific properties to try to
> make indenting work better in multi-mode buffers.

You mean, you are setting the STTP to a harmless value (say the WS code)?
In that case, how do you go about restoring the STTP value to what the
major mode might have set it to?

> Basically, nothing works perfectly.  The global syntax-table doesn't
> work completely satisfactorily in multi-mode buffers.  Syntax-table
> text properties involve enormous overhead and also do not work well
> enough.

Isn't this sort of thing one of the reasons the syntax-table TP was
invented?  Surely the overhead can't be that bad (at least, not in GNU
Emacs - I've heard that it can cause significant performance hits in the
other Emacs, though).

> The real problem involves resolving the dichotomy between linear
> editing and the discontinuous nature of multi-mode files.  I don't
> really have a perfect solution right now.

It feels like we could do with some sort of support in the core for
multiple sections.  Something a bit like a region, or a narrowed section,
but independent of them, inside of which font-locking, indentation and so
on would be calculated.

> /Joe

-- 
Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").