[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#16915: 24.3.50; [ruby-mode] Comments in regexps using the extended s
bug#16915: 24.3.50; [ruby-mode] Comments in regexps using the extended syntax are not font-locked properly
Wed, 12 Mar 2014 09:48:01 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
On 10.03.2014 16:40, Stefan Monnier wrote:
We usually use syntax-tables for that. They do provide more flexibility
than needed (so far), such as making it possible to allow different
commenting conventions within the new context. But it seems like
a "simple" way to handle the problem, so the extra generality is a bonus.
To handle this part of the problem (literals within literals), yes,
(but - and this is a change from certain other multi-mode uses - still
fontify uncommented text inside them with the regexp face). But in the
general case, we would at least want to be able to change
`font-lock-keywords' can use `syntax-ppss' to decide which rules to use
(since syntax-ppss would have to include the "context state" somewhere
in its output). It's not terribly convenient to do currently, so we may
want to provide a new replacement for font-lock-keywords which makes it
easier (and avoids relying on "eval" while we're at it).
If we're speaking of multiple modes in general, syntax-ppss might not be
enough to determine which keywords to highlight. Even if it includes
information about new syntax classes.
Suppose we have an HTML file with <script> and <style> tags inside.
Would points inside of these tags have different states? What might be
the difference between them?
Would some font-lock code compare syntax table reference attached to a
syntax class, with a syntax table it wants?