Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Support templates in non-lithtml code #19

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.

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

Successfully merging this pull request may close these issues.

2 participants