bug#24749: Making sure syntax-propertize is called

[Vitalie Spinu]

>> On Tue, Jun 04 2019 09:08, Stefan Monnier wrote:

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

Ideally yes, but I cannot control for what users use. To be frank I was not even
paying attention to this in my own regexps so far. I think constructs like \\w
or \\s- are pretty common.

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

Good to know. I was not aware of this. 

Relatedly, I just noticed that seemingly innocuous dabrev-expand (hippie-expand)
trigger syntax-propertize for the entire buffer. In large buffers, especially if
you have several of these, the delay is noticeable.

> IIRC (and similarly, syntax-propertize wouldn't be applied to the whole buffer
> if a match is found before EOB).

In the multi-mode context some types of chunks might not be present in the
buffer, and the rare ones are commonly not. So the search ends up at eob.


  Vitalie