bug#24749: Making sure syntax-propertize is called

[Vitalie Spinu]

>> On Mon, Jun 03 2019 15:45, Stefan Monnier wrote:

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

Arh. Right. It's a chicken-egg then, syntax-propertize is triggered by search
when parse-sexp-lookup-properties are t, but parse-sexp-lookup-properties is set
by syntax-propertize. So an external tool (font-lock) was needed to
syntax-propertize for the first time before this patch. Things are not
particularly elegant, are they?

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

Would you consider a patch which sets it to t by default and removes the
auto-resets? It's hard to imagine that it would break anything.

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

Ok, but then setting parse-sexp-lookup-properties to t by default would not harm
such a mode. 

Instead, one can imagine a scenario when a mode doesn't want to use syntax
tables but would like to use syntax-propertize to install various text
properties (to be used in font-lock or just caching buffer structures
etc). Current situation harms such modes by re-setting
parse-sexp-lookup-properties to t on various occasions.

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

I am setting it to nil while searching for mode boundaries in polymode. First,
it doesn't make sense to use local syntax tables in search because different
inner modes might have a different opinion of syntax. Second, I don't want to
trigger syntax-propertize for performance reasons. The bounds of the forward
search is normally eob and that would mean syntax-propertizing the entire buffer
on every mode boundary lookup.


  Vitale