Closed CypherPotato closed 10 months ago
Example has 3 vars.
3rd: easy to see that it uses HTML lexer, so possible for Cud to change it. But it will slowdown the parsing like any sublexer ruler does. so I don't like the idea.
1st/2nd: not detectable that it's HTML or JS syntax, so how Cud can detect it?
in the first example, at the var foo
, there's no HTML literal. The JS literal is always enclosed by ${...}
, where it contains the string interpolation expression. At it, ...
expects an javascript expression.
the next two examples contains an HTML template literal. you could interpret that is an HTML literal by the most used rules:
backstick -- whitespace? --
or
/*html*/
or html
-- backstick -- contents
I don't see how this could slow down the lexer. For backsticks that do not comply with this rule, the interpretation is only that which understands the JavaScript interpolated with ${...}
, from the first backstick ' into the first ocurrence of ' or ${
, whichever appears first.
For HTML Template Literals, you could just interpret '\s*\<
or even (html|\/*html*\/)\s*'
.
We can always include sublexer HTML but it must be some special version of HTML, which handles ${...}
and includes JS. So JS lexer includes HTML lexer (level 1) which includes level 2 - JS again.
Too complex task.
What you can do here: install one of these 3 JS lexers
and edit it. https://wiki.freepascal.org/CudaText#Lexers_modification_and_creation
JavaScript syntax when using backsticks on CudaText 1.208:
JavaScript syntax on VSCode:
You can see that the second editor recognizes HTML and JavaScript expressions within
${...}
inside backstick strings. This should be recognized on CudaText too.