On Feb 10, 2008, at 9:22 AM, Thomas Aylott - subtleGradient wrote:
But what are the downsides? Adding too many irrelevant scopes to the document. When converting the scopes to HTML you get a giant glob of carp at the beginning of every line. That could be averted with a simple blacklist of scopes that should be ignored from the conversion process.
Other than that, what's other downsides are there?
Well for Javascript this isn't a downside, since it doesn't have any line-based scopes. But most grammars match entire lines at some point, adding tab scopes to each of those would get very messy quite fast. Depending how many tabs you allow that's 5+ captures, double it if you have a different scope for spaces over tabs like your current version does for each rule.
Speed-wise I'm not sure what kind of hit it takes from assigning the tab scopes, allan could perhaps answer this.
--
Another thing to ask here is how it could be implemented as a TextMate level feature.
I see two approaches, one is basically what you do. Have some dynamic scopes added for each leading tab/soft-tab, can color these in themes. Logistically pretty simple I'd imagine, not much to figure out.
The second is what people have pointed out here before as cool, the more XCode like coloring:
http://skitch.com/infininight/gdfw/nstextview-edit-in-textmate.mm
Where it colors blocks not really the tabs themselves. A bit niftier perhaps? But logistically harder perhaps. Are they no longer based on tabs at all, or are they simply anything foldable gets a new 'level'? If they are still tab based what do you do about something like a two- line item when the second line is indented, you wouldn't want it made a new 'level'. The limitation here is the places where the folding system isn't ideal, but then that's something that will hopefully improve so tieing them together might make it easy.
Any other ways this could be done?