Re: eLisp fontlock with mmm-mode

["Stefan Monnier" <monnier@iro.umontreal.ca>]

> syntax-table properties are in constant use in AWK Mode (also part of CC
> Mode).  I've never felt they impacted the performance significantly, even
> on my 166 MHz dinosaur.  But, then again, large AWK buffers are rare.  My

They are also heavily used in CPerl-mode and also (tho less heavily) in many
other major modes.  The performance impact should indeed be small in
general.  In typical uses, the main performance impact is the time taken to
compute/add the properties themselves, not the time to look them up
during parsing.

> OK.  This approach rules out the use of the syntax-table property by
> major modes, if they are to be used in MMM Mode.  :-(

Unless the major mode uses font-lock to add those properties and mmm-mode is
careful to tell font-lock to re-adorn the syntax-table properties
when needed.

> Maybe it would be possible to adapt the core to support several ST text
> properties simultaneously (e.g. syntax-table, syntax-table-cc,
> syntax-table-mason, ....), and to setq parse-sexp-lookup-properties to
> one of these symbols rather than simply t.

It's probably easier to use overlays.

>> Unfortunately, indentation engines and font-lock engines, at least as
>> implemented by cc-mode, rely on a combination of syntax-table
>> properties and regular expression searching to accomplish their tasks.

> "Unfortunately"?  How else could CC Mode do it?

Using syntax-tables only.  But yes, that would be somewhere between
impossible and very painful.

>> For example, take a noweb file.  This consists of a literate program,

> As an aside, could you explain what a "literate progam" is, exactly?
> What it's for, who uses it, and so on.

It a coding style that thinks of a source file as "description of the program,
interspersed with the actual code" rather than "the code interspersed with
comments".
You can typically run the file through TeX to get a beautifully typeset
description of your code, or you run it through some other filter to
extract the actual code and then compile it.

It might look like:

  ...
  \section{Parsing the input}
  To parse the input we define a \emph{function} \kw{foo}:
  \begin{code}
  void foo (int a, int b, char *c)
  {
     ...
  }
  \end{code}
  ...

So you need both latex-mode and c-mode in the same buffer.

> analyzing then in the backwards direction (necessary for doing the
> indentation) is even harder than in the forwards direction (like a
> compiler does).

I see you've learned the secret ;-).


        Stefan