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

Re: [patch] Add a 'modifier' keyword to the :syntax commands, allowing syntax matches to stack.

Expand Messages
  • Charles Campbell
    ... I just am letting you know that I m interested in this modification, too. I have two plugins (hilinks.vim, which allows one to see which syntax and
    Message 1 of 14 , Dec 6, 2012
    • 0 Attachment
      Ben Fritz wrote:
      > On Wednesday, December 5, 2012 10:47:42 PM UTC-6, So8res wrote:
      >> Oops, sorry, I was misunderstanding how synID* worked.
      >>
      >> I've updated the patch to add the "combine" {what} to synIDattr, which is the bare minimum we need here.
      >>
      >> synID should definitely return only one ID in this case, both because we don't want to duplicate synstack and because it's the only way to get interoperability with the extended links patch.
      >>
      >> I'm still not sure how best to deal with synIDattr. How would you feel about adding a [, {flatten}] argument to it that flattens out the stack before checking the attr (analagous to [, {trans}] in synID)?
      > I like that idea, but in order for it to work it would need a row+col because the attributes for combined items depend on what they are combined with which depends on where in the document you are.
      >
      > So I guess I could get the attrs flattened always at a particular row and column, then if the "combine" item shows that at least one item in the flattened view is a combining syntax item, look at the syntax stack for the names used.
      >
      > The problem I see is in detecting two regions side-by-side with the same top-level (combining) syntax item but different underlying syntax stacks which therefore need different highlighting. I'd like to do this without checking the entire stack for every character in the document which I believe will be much slower than otherwise. I suppose I could keep a list of synIDs which combine and only check the stack for those but I'd still like a faster method.
      >
      I just am letting you know that I'm interested in this modification, too.

      I have two plugins (hilinks.vim, which allows one to see which syntax
      and highlighting group(s) are active under the cursor; and synchk.vim,
      which is a personal plugin which compares syntax highlighting
      correctness (converts syntax highlighting IDs for various test files
      into line-by-line hashed codes using
      synIDattr(synID(line("."),col("."),1),"name"); I can compare proposed
      changes to syntax highlighting plugins with the previous highlighting of
      the test files, thereby permitting some automated syntax highlight
      checking)). Obviously, if synID* will be returning lists, I may need to
      change these plugins to accommodate that.

      I see other users of synID* : SrchRplcHiGrp.vim (David Fishburn),
      foldutil.vim (Hari Krishna Dara), 2tex.vim (Francois Rigault), in my own
      files. I'm certain that there are many more plugins on vim.sf.net that
      may be affected.

      I think that perhaps [,{flatten}] should be the default, and
      [,{expanded}] give out the list.

      Regards,
      Chip Campbell

      --
      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
    • Nate Soares
      Oh, right, of course we can t have a {flatten} arg in synIDattr without knowing the row/column. It seems like the right thing to do here is have synID return a
      Message 2 of 14 , Dec 6, 2012
      • 0 Attachment
        Oh, right, of course we can't have a {flatten} arg in synIDattr without knowing the row/column.

        It seems like the right thing to do here is have synID return a list of IDs being used, and have synIDattr take a list of IDs and flatten them when looking up an attribute. This has the nice property that existing code keeps working, and that flattening is the default. You can still pull any id from the list and call synIDattr on it alone if you want the "non-flattened" attribute.

        The complexity comes when you try to integrate this behavior with the extended link behavior: what happens when you are using both extended links and combining syntax? My inclination is that synID creates a flat list of *all* highlight groups being used. The user can use the synIDattr(..., "combine") on each element to tell if it comes from an extended link or a syn-combine if they really need to, but in the average case they'll probably just pass the list on to synIDattr.

        --
        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
      • So8res
        synID now returns a list. synIDattr now takes a list. They both still handle the single-id case, but the code s a bit messy and the name is stale. I think we
        Message 3 of 14 , Dec 6, 2012
        • 0 Attachment
          synID now returns a list.
          synIDattr now takes a list.

          They both still handle the single-id case, but the code's a bit messy and the name is stale. I think we should add synActive and synActiveAttr, which take/return lists instead of single numbers, and then deprecate synID*.

          --
          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
        Your message has been successfully submitted and would be delivered to recipients shortly.