|
From: | Dmitry Gutov |
Subject: | bug#16915: 24.3.50; [ruby-mode] Comments in regexps using the extended syntax are not font-locked properly |
Date: | Wed, 12 Mar 2014 09:48:01 +0200 |
User-agent: | 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, certainly.
(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, too.`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?
[Prev in Thread] | Current Thread | [Next in Thread] |