Skip to content

Support templates in non-lithtml code #19

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

schrotie
Copy link

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

Allow custom tagging of templates, so it works without lithtml
@jonsmithers
Copy link
Owner

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
Copy link
Author

schrotie commented Sep 27, 2020

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.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants