bug#24749: Making sure syntax-propertize is called

[Stefan Monnier]

>> Indeed, font-lock is the most common caller of syntax-propertize, so
>> that explains why interactive use typically is not affected.
> It's a bit tricky actually. AFAICS font-lock installs it only when
> font-lock-syntactic-keywords are defined and syntax-propertize-function is not
> defined.

No, no: what font-lock does is *call* syntax-propertize.
The font-lock-syntactic-keywords stuff is just obsolete backward
compatibility cruft.

> The latter condition was undefined for me.  So I still have no clear
> idea what actually is setting the value.

It's syntax-propertize which sets parse-sexp-lookup-properties ;-)

>> Note: you can also set parse-sexp-lookup-properties's default value to
>> t and forget about the problem ;-)
> Why not make it the default then?

No idea.

> There is a clear redundancy between the two. If a mode defines
> `syntax-propertize` then it must set `parse-sexp-lookup-properties`,

Indeed, which is why syntax-propertize sets it.

> and the other way around.

Actually the other way around isn't quite true: a major mode may decide
to use the syntax-table text-property but set it by hand its own way
rather than via syntax-propertize.

> It seems that the only(?) use case for a nil `parse-sexp-lookup-properties` is
> to set it to nil dynamically in specialized lookup code for performance
> reasons. Such code does let-bind it to nil already.

I can't remember binding it to nil for performance reasons (tho maybe
that's the reason behind yasnippet.el's case), but we do let-bind it
temporarily to nil in a few cases as a hackish way to have a "different
view" of the buffer which happens to fit our needs.  E.g. this is done
in font-latex.el and sm-c-mode.el.


        Stefan