bug#24749: Making sure syntax-propertize is called

[Stefan Monnier]

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

I see you understand ;-)

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

It's not my call to make, but I won't oppose it, no.

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

No, and I can't think of a case where it would cause harm other than
maybe a potential possible slowdown.

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

That also means that the regexps you use there presumably don't use
syntax-dependent constructs like \s?, \<, and friends, right?

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

If your regexp doesn't use syntax-dependent constructs, then the regexp
search shouldn't call syntax-propertize, IIRC (and similarly,
syntax-propertize wouldn't be applied to the whole buffer if a match is
found before EOB).


        Stefan