Loading ...
Sorry, an error occurred while loading the content.

Re: Questions, Thoughts, and Experiments with `main_syntax` and html.vim

Expand Messages
  • Amadeus Demarzi
    I have attached a patch for this fix. It essentially amounts to the change that I mentioned at the end. Would it be possible to get this patch in? Cheers,
    Message 1 of 2 , Jul 19, 2013
    • 0 Attachment
      I have attached a patch for this fix.

      It essentially amounts to the change that I mentioned at the end.

      Would it be possible to get this patch in?

      Cheers,
      Amadeus

      On Wednesday, July 17, 2013 12:16:25 PM UTC-7, Amadeus Demarzi wrote:
      > 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 vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    Your message has been successfully submitted and would be delivered to recipients shortly.