bug#24749: Making sure syntax-propertize is called

[Vitalie Spinu <spinuvit@gmail.com>]

>> On Mon, Jun 03 2019 13:47, Stefan Monnier wrote:

> 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. The latter condition was undefined for me. So I still have no clear
idea what actually is setting the value. Likely some third party. 

I pulled quite some hair till I figured how things work. So I wonder if a few
words documenting the parity between `syntax-propertize` and
`parse-sexp-lookup-properties` could be added to (preferably)
`syntax-propertize` docstring. Currently the only "doc" is a comment in
`run-mode-hooks`, which is the last place someone will look for it.

╭──────── #1982 ─ /home/vspinu/bin/emacs/lisp/subr.el ──
│          ;; `syntax-propertize' sets `parse-sexp-lookup-properties' for us, but
│          ;; in order for the sexp primitives to automatically call
│          ;; `syntax-propertize' we need `parse-sexp-lookup-properties' to be
│          ;; set first.
╰──────── #1985 ─


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

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

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.

  Vitalie