Re: eLisp fontlock with mmm-mode

[joe-gg@zircon.seattle.wa.us (Joe Kelsey)]

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.

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

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.

/Joe