[TxMt] punctuation.whitespace.function-call.leading.c

[Thomas Aylott - subtleGradient]

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?