RE: Clarification needed: syntax-propertize vs font-lock-syntax-table

["Wedler, Christoph" <christoph.wedler@sap.com>]

> On 11/18/2015 08:06 PM, Wedler, Christoph wrote:

>>   * Solution 1: the font-lock syntax table must not differ too much from
>>     the normal syntax table, i.e., the function in

> I think this is the current consensus. It shouldn't differ in paren, 
> comment or string syntax. IOW, it should be syntax-ppss-compatible with 
> the main one.

OK, fine with me.

>     syntax-propertize-function should behave the same.  If so, it should
>     be probably documented.

> It should.

And syntax-propertize should be called at more places.  Currently, doing
it lazily does not really work, as it is not called when needed.  That
is why js-mode calls (syntax-propertize (point-max)) at the end (and I
will do the same in antlr-mode).


My other question was concerning (nth 9 ppss), i.e. the list of open
parentheses is very useful to have (and its also used in syntax.el
itself) -> I would like to have this to be official in the lisp
docstring as well - in src/syntax.c, we have

  struct lisp_parse_state
    {
      [...]
      Lisp_Object levelstarts; /* Char numbers of starts-of-expression
  				 of levels (starting from outermost).  */
    };


>> Any other ideas?

> Support different syntax tables in different parts of the buffer. That 
> must be a part of our eventual multi-major-mode solution.

In the case of antlr-mode (grammar with actions), it could be done as
long as it does not break the calulation of the "inner-mode-chunk-end",
e.g, with Python actions

   rule: "KEYWORD" { do_something {  } # do it };

the action ends with the final "}" (even though a naive Python-like
syntax-propertization would think of it as part of a comment)