search

jonsmithers / vim-html-template-literals

Syntax highlighting for html template literals in javascript (as in lit-html and polymer 3)
MIT License
71 stars 10 forks source link

Support templates in non-lithtml code #19

Open schrotie opened 3 years ago

schrotie commented 3 years ago

Hi Jon

I wanted your highlighting (thanks a lot!) but I don't use lithtml. So I adapted your "start" regexp to also parse "/ html /`" (and css). This syntax is taken from an atom plugin I've been using (https://github.com/vokeio/language-javascript-plus).

Cheers
Thorsten
jonsmithers commented 3 years ago

Hey, thanks for the PR!

Has this been done in other IDEs besides Atom? If this tactic is a little niche, it would probably make sense to hide it behind a flag. Maybe something like let g:htl_html_tagged_with_comment=1.

An alternative hack I've used in the past is to define html as a pass-through function: const html = (s) => s.raw[0];.

(Perhaps in an ideal world, vim would "guess" if an untagged template contains html or css or whatnot and highlight it accordingly.)

schrotie commented 3 years ago

I don't know if this has been done in other editors. It is certainly a common problem but I don't know about other solutions. I guess what you are doing is the special case (i.e. using lithtml specific syntax as a trigger). You have HTML template strings in Vue and React, too, and in my case in vanilla EcmaScript. Obviously I believe vanilla should be the default and everything else is weird niches, but I have to concede that I'm the niche :-) So yeah, a flag is fine. However, I would toggle comment-tagging in general (i.e. for CSS, too, once that works) so the name should be more generic.

I don't think guessing is a good idea. If you guess wrong (and you will) then you may mess up the highlighting of the whole file.

Edit: I thought about this some more - the probability of accidentally triggering a comment-tag highlight is so low, the harm so little and the fix so simple that I think an extra flag is not warranted.