[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24749: Making sure syntax-propertize is called
From: |
Vitalie Spinu |
Subject: |
bug#24749: Making sure syntax-propertize is called |
Date: |
Tue, 04 Jun 2019 07:49:22 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
>> 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