:syntax include across runtime and plugin boundaries

[Devin Weaver]

Dear fellow Vim devs:

Thanks for taking the time here and forgive my naïve attempts at understanding the landscape for this. I apologize if my mental model is inaccurate for this topic.

I work on a project that recently changed development paradigms. They went from separate files for the logic and the presentation template each a separate language. The base program syntax (JavaScript) exists in a single .js file while the template syntax (Handlebars) exists in a separate .hbs file.

This works as the javascript syntax exists in $RUNTIME as well it is enhanced by the vim-javascript¹ plugin. The handlebars syntax comes from the vim-ember-hbs² plugin.

In newer versions of the Ember development environment these have been merge into a single file. In much the same way JSX merged javascript and HTML. The more complicating factor is that handlebars merges with the RUNTIME html syntax, so now there are three syntax languages being squished into one.

In my naïve attempts I tried using :syntax include but ultimately failed.

Most of the knowledge base for Ember has moved to NeoVim leaning on tree-sitter and Lua. Leaving any porting to VimScript as an exercise only suited for masochists perhaps ― will Vim ever consider embedding tree-sitter?

Another complicating factor is the mentioned plugins for syntax highlighting mentioned above have not been touched in many years making their relevancy questionable even though their use has yet to have been adopted to the $RUNTIME proper.

I'm asking for help as I feel I've reached the edge of my social skills level to navigate this both technically and politically.

What are the steps or blockers to adopting these syntaxes into the Vim runtime core code? Is that even a good course of action?

How do we update these disparate syntaxes such that they are all compatible with :syntax include ― something the documentation seems to leave unanswered.

Has the level of complexity for this language(s) reach a point that something like tree-sitter is a better option and is this an example where the minimalist philosophy of Vim meets its limit?

If anyone has interest in helping I'm looking for next actions and suggestions on how best to reconcile the current messiness of three different plugins and possibly how to develop syntaxes in VimScript best suited for mixing as paradigms change.

I should also note that there was some initial work³ added to support this but due to the maintenance and separate projects involved it didn't do much to get syntax highlighting for these single files.

Thanks again for taking the time to understand and consider.

Yours in service, Devin (Sukima)

¹ https://github.com/pangloss/vim-javascript
² https://github.com/joukevandermaas/vim-ember-hbs
³ https://github.com/vim/vim/pull/9799

[Christian Brabandt]

On Thu, 16 Jan 2025, Devin Weaver wrote:

> In my naïve attempts I tried using :syntax include but ultimately failed.

What does this mean?

> Most of the knowledge base for Ember has moved to NeoVim leaning on
> tree-sitter and Lua. Leaving any porting to VimScript as an exercise

What do you mean with knowledge base has moved on? Certainly the
knowledge shouldn't be lost that easily on native legacy Vim support.
And even for Neovim users, it might be good to at least document how to
make use of legacy Vim script to help users coming from Vim or using
still Vim.

> only suited for masochists perhaps ― will Vim ever consider embedding
> tree-sitter?

Yes, someone just has to do the work on "embedding tree-sitter". This
will require a bit of hard-work.

> Another complicating factor is the mentioned plugins for syntax
> highlighting mentioned above have not been touched in many years
> making their relevancy questionable even though their use has yet to
> have been adopted to the $RUNTIME proper.

I am not sure what you are trying to say here.

> What are the steps or blockers to adopting these syntaxes into the Vim
> runtime core code? Is that even a good course of action?

What syntaxes specifically. If you need them, no would be a good time to
volunteer to maintain them. That would make them suitable for inclusion
in to the $VIMRUNTIME if that is what you are asking.


Thanks,
Christian
--
The little girl expects no declaration of tenderness from her doll.
She loves it -- and that's all. It is thus that we should love.
-- DeGourmont