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
