feat: support JavaScript syntax on template

[vhoyer]

This support:

1. Non-zero length dynamic values (:attr="variable");
2. Zero length dynamic values (:attr="");
3. Slots syntax (#name) now have JavaScript syntax also (#default="{ thisHere }");
4. Dynamic values with a string right at the begining and the end (v-text="'foo'");
5. Dynamic keys (:[thisHere]="{ thisAlso: 1 }");

There is also comments explaining commands and the mustache syntax is considered htmlSpecialChar, because it's easier to see them that way.

Closes #143

[vhoyer]

Oh wait, this has a bug :sweat_smile:

<img
  :alt="'foo bar baz'"
>

this is breaking the syntax :thinking: donno how to fix, I wouldn't merge this right now

[vhoyer]

Fixed, we can merge again :sweat_smile: :joy:

[vhoyer]

So I've been using it for a while and haven't seem anymore errors

[vhoyer]

here is an example image of the syntax :D

P.S.: As a side note for the future, I'd like to state that this is not an example of how I code, just a example of the various ways the syntax might show up mashed up in one example :D :sweat_smile:

[adriaanzon]

Hi! First of all, thanks for all the effort! Looks very promising.

I took some time to try it out with a barebones vim config (including othree/html5.vim and pangloss/vim-javascript) but it didn't seem to fully work for me.

In this basic example, the class attribute binding doesn't get highlighted as JavaScript. Can you see what is going wrong here?

[vhoyer]

hey, I'm investigating this and I discovered that if you insert in your .vimrc also the line:

let g:vue_pre_processors = []

The hightlighing begins to work, but now my lunch break is over, so I will continue investigating this asap :smile: thanks for the feedback :heart:

[vhoyer]

Other discovery is that: having

      \ {'name': 'pug',        'tag': 'template', 'attr_pattern': s:attr('lang', '\%(pug\|jade\)')},
      \ {'name': 'slm',        'tag': 'template'},
      \ {'name': 'handlebars', 'tag': 'template'},
      \ {'name': 'haml',       'tag': 'template'}, " <<<<- this here
      \ {'name': 'typescript', 'tag': 'script', 'attr_pattern': '\%(lang=\("\|''\)[^\1]*\(ts\|typescript\)[^\1]*\1\|ts\)'},
      \ {'name': 'coffee',     'tag': 'script'},
      \ {'name': 'stylus',     'tag': 'style'},

source

breaks the syntax :thinking:

when I remove the haml line, it works, very strange...

[adriaanzon]

Interesting, I also remember having to change the order of that array in order to make some syntax highlighting work.

I can confirm that it works when I set let g:vue_pre_processors = 'detect_on_enter', which is what I would normally use.

Maybe it's reasonable to use 'detect_on_enter' as a default (related: #128). The drawback is that it doesn't highlight new preprocessors as you type, but I think that's fair. When Vim detects shell scripts without file extension, you also have to manually reload the buffer using :e after setting the shell in the shebang (#!) line. Changing to 'detect_on_enter' will also allow us to add more languages (from pending PRs) without slowing down the initial load time.

[vhoyer]

Yeah, I guess I do agree with you regarding the "detect_on_enter" on default.

But the problem happens when the haml syntax loads. When you use "detect_on_enter", do you use haml? (Because I don't, that's why I hadn't seen the bug before)

[vhoyer]

Ok, I'm thinking about it here, I have the smallest clue about using haml and a even smaller one about using haml with vue, but for what I could see in some examples here on github... I don't think the code I made even applies anyway, because the syntax is really different, in fact I think this same logic applies to the other langs for template too, so what I'm thinking here is, that I make adjustments to this PR to make it only work in template without any other lang loaded into it, what do you think, @adriaanzon ?

[adriaanzon]

Yeah that seems like a good solution to me.

If we ever want to add support for this to other templating languages, we will probably need to make specific adjustments anyway.

[vhoyer]

So, I've mauled over this problem for a while now, and I just can't find a way to make this work without changing the default value of g:vue_pre_processors to detect_on_enter.

Do we agree on changing the default value for this option? And if so, can someone help me with the tests that are breaking? 😅 sorry for the trouble 🙁

[adriaanzon]

I think the tests are failing because not all languages are loaded now. Maybe it's best to add support for setting the option to 'all', so that it loads all of the supported syntax files. This can then be used in our Vader tests and by users who want the old behavior back.

[vhoyer]

technically using all already work, right? 'cause of the

function! s:should_register(language, start_pattern)
  " Check whether a syntax file for {language} exists
  if empty(globpath(&runtimepath, 'syntax/' . a:language . '.vim'))
    return 0
  endif

  if exists('g:vue_pre_processors')
    if type(g:vue_pre_processors) == v:t_list
      return index(g:vue_pre_processors, s:language.name) != -1
    elseif g:vue_pre_processors is# 'detect_on_enter'
      return search(a:start_pattern, 'n') != 0
    endif
  endif

  return 1
endfunction

Should we add an explicity elseif g:vue_pre_processors is# 'all' too? maybe in that case also change the fallback return to 0? (that way the all keyword check would make more sense).

maybe just a comment on the script "hey, all is a valid keyword"?

[vhoyer]

also, I think it would be better from the user perspective if we mantain the ability to pre-load some resources, so how about we adopt an api like this:

  let g:vue_pre_processors = ['scss', 'detect_on_enter']

Thoughts?

[vhoyer]

Now it also highlights script stuff inside the template for other script languages like typescript and coffescript