Re: eLisp fontlock with mmm-mode

[Joe Kelsey]

Alan Mackenzie<none@example.invalid> wrote in message 
news:<7vsqjb.r5.ln@acm.acm>...
> 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:
> > 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?

The maintainer of mmm-mode felt that turning on
parse-sexp-lookup-properties might impose unacceptable overhead on
buffer activities.  I have no direct evidence of any performance
penalties due to turning on parse-sexp-lookup-properties, but I bow to
the owner of mmm-mode in his personal decisions.

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

I created a function to apply a syntax-table property to a set of
regions like this:

(defun mmm-space-other-regions ()
  "Give all other regions space syntax."
  (interactive)
  (mmm-syntax-other-regions (string-to-syntax " ") nil)
  (setq parse-sexp-lookup-properties t))

which eventually calls the following on each region (the definition of
mmm-syntax-other-regions does not matter to this discussion):

(defun mmm-syntax-region (start stop syntax)
  "Apply a syntax description from START to STOP using the syntax cell
SYNTAX.
Sets the local text property syntax-table to SYNTAX in the region.
If SYNTAX is nil, then remove local syntax-table property."
  (if syntax
      (add-text-properties start stop (list 'syntax-table syntax))
    (remove-text-properties start stop '(syntax-table nil))))

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

You seem to feel that some sort of "narrowing" function might work. 
However, in reality, when you look at multi-mode buffers as supported
by mmm-mode, narrowing by itself does not provide enough context. 
Unfortunately, indentation engines and font-lock engines, at least as
implemented by cc-mode, rely on a combination of syntax-tasble
properties and regular expression searching to accomplish their tasks.

For example, take a noweb file.  This consists of a literate program,
actually a mixture of LaTeX and code in what Norman Ramsey calls
"chunks".  Each documentation chunk describes ideas behind surronding
code chunks.  Part of the literate programming style involves the
tangle and weave processes.  Tangling means reassembling the disjoint
code chunks from a web file into a choerent whole for presentation to
the compiler.  Weaving involves processing the entire web to markup
sections appropriately, applying pretty-printing markup to the code
and adjusting the web syntax markup to fit the documentation
processor, such as LaTeX or HTML.

While editing such buffers, you want to present different views of the
buffer in different sections.  For instance, if you want to edit the
documentation, then you want latex-mode to treat the code chunks as a
single unmovable piece, essentially a syntactic word and not attempt
to reformat it using its own peculiar ideas of paragraph formatting.

Meanwhile, while editing code, you want cc-mode to completely ignore
the documentation chunks.  One of the most frustrating parts of this
comes when cc-mode spots an unterminated apostrophe in a preceding
documentation chunk and treats it as an unterminated string, thus
compeltely screwing up the indentation of the code.  Also, you may
want to consider disjoint code sections as virtually appended to each
other in order to carry forward indentation from one to the other. 
Also, you may want to ignore other code sections depending on how
related they are to each other, since the tangle process may move them
around into different places, including separating them into
completely different files (.c versus .h).

I want to have "virtual views" of a buffer imposed upon major modes in
order to restrict how far afield their regular expression linear
searches can carry them.  Thus, I want to specify a set of regions
which cc-mode can consider virtually catenated in order to restrict it
to only looking at characters in that view.  Then it can use all of
the regular-expression optimizations to supplement syntax-table
properties it wants in order to work correctly in multi-mode buffers. 
Something like narrow-to-region, but given a list of disjoint regions
to narrow to.

/Joe