On Feb 11, 2008, at 3:43 AM, Michael Sheets wrote:
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.
There are a few places where I've had to capture the leading space, but you just have to include the #leading-space thing and you're good to go. Obviously wouldn't work if that space was taken in a different way though.
Speed-wise I'm not sure what kind of hit it takes from assigning the tab scopes, allan could perhaps answer this.
That is definitely something to consider. Unfortunately it's currently impossible to run tests on a language grammar. I'd like to see that as a feature sometime in the future. Maybe hook into the mate function to test any tmlanguage file against any text file and get some statistics or something useful. Maybe a breakdown of what scopes are taking how long so that you can focus your energies on fixing that stuff.
I know there are a million different ways of doing a regex, and some ways are much more betterer than others. So anything that can help me see which of my regex look to be written by rabid lemurs would be useful.
--
Another thing to ask here is how it could be implemented as a TextMate level feature.
I see two approaches,
Actually, I think it actually makes good sense to make it 2 separate features. Style the leading space dynamically AND Xcode-esque dynamic nested group coloring.
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.
I think it could be like we currently have "Highlight current line" as a preference checkbox and a hardcoded theme color. If we just standardize on odd-tab coloring checkbox+theme color. Then it's very simple. That way the textmate level implementation of it is really none of our business, Allan can make it happen however he likes without polluting the scope structure with otherwise worthless scopes.
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.
This is really a completely different feature.
I love how Xcode has it built into the folding system. It also solves the issue for themes where too many nested groups can become unmanageable. In my current implementation I have to manually add each group with its background color hard coded. Themes could instead have 3–4 background colors that are manually set, or else textmate will fallback to some sort of default. And then have a checkbox in the prefs like "Highlight current line"
I'd also like the option of activating the coloring based on caret position instead of having to mouse over the gutter like in Xcode.
So, yes. Based on folding is probably the best option for this feature.
I also REALLY like the way xcode folds code into a single character instead of folding into a single line like textmate currently does.
Any other ways this could be done?