This is probably going to be a bit long winded, so bear with me. As a preface, I do a lot of HTML/CSS/Javascript development in vim. I use both a special Javascript ( https://github.com/amadeus/vim-javascript ) and CSS ( https://github.com/amadeus/Better-CSS-Syntax-for-Vim ) plugin that override the built in runtime syntax files which improve css and javascript support (for my workflows anyways).
In general they work great on their native file types, no issues there. However, I noticed that they aren't properly sourced/used when viewing/editing HTML files. I am fairly novice when it comes to Vim's syntax architecture, but after playing around with things, I think I figured out how things work, but it also introduces a couple questions, since I don't know if the things that I have issue with are by design, or if they are actually bugs. So here goes. In general, syntax files all seem to contain a similar batch of boilerplate at the top, see this gist for an example of it: https://gist.github.com/amadeus/b836fb8effee5729be2e/7fe89f62cfda242a65b428219e71fc56d72843a0 Obviously you can substitute the string javascript for the relevant syntax type. Then at the end of the file you get this other boilerplate: https://gist.github.com/amadeus/b836fb8effee5729be2e/6550884417ed507a16ad9aec10d86dec0b9989a2 So from what I can gather, when you open, for example, a Javascript file, it first loads the plugin's JS file, since main_syntax doesn't exist, it will create it, and set it to `javascript`, it will apply all the syntax code, then at the end, it will remove that main_syntax variable via the unlet, BUT ONLY if it's set to `javascript`. Then, vim will attempt to source the builtin JS file, at which point, there will be no `main_syntax` variable, therefore it will perform its check for `b:current_syntax`, which in the case of my Javascript plugin, was set, therefore it will finish/return immediately without applying the built in JS syntax code. All good so far, however it gets weird with the HTML file. When you source an HTML file, it creates it's own `main_syntax` variable set to `html`. When it gets to the point of sourcing my Javascript plugin, it will entirely skip the `main_syntax` check because `main_syntax` exists due to the html syntax file. This means it just executes the JS syntax file normally. Then, when it gets to the end of the JS file, it gets presented with this: https://gist.github.com/amadeus/b836fb8effee5729be2e It will not unlet the `main_syntax` variable because it is set to the string of `html`. This means that when vim then sources the builtin JS file, that lack of a `main_syntax` that should normally abort the built in JS sourcing gets skipped, and the default JS file then overrides/clobbers the built in JS file. So the first question I have, is this by design? Is the intention of the built in html.vim file to never allow a plugin JS file apply to the <script> tags? I assume this is not the intention, and obviously there are a few ways to fix this. I think probably the most elegant way would be to update all runtime syntax files that could be executed in mixed environments to something like this: https://gist.github.com/amadeus/b836fb8effee5729be2e/64d7a3735a98b04f239bde4748f3a19e26a5f9bc Since it should mean that external plugins would not need to change what they are doing. However, I am not familiar with this system enough to ensure whether that could introduce other bugs. There are other fixes, however they involve fixing the plugins to unlet main_syntax when it == `html`. Of course. then the html.vim syntax file needs to then reset the main_syntax variable to `html`. That just seems really messy since you have to change things in many places. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
