Sublime Forum

BracketHighlighter2 BETA Branch

#6

Ahh. I got it now.

What I will do is add a global style object that will have a default icon, style, and color in it. If you want an entry to pick up something from the global object, you will just not define it in the bracket definition.

So in your case, you would remove the color and style parameter from all of the bracket definitions to pick up the global style and color. That way, people who like different styles for different brackets can still define separate colors and styles, and people who like one consistent color and style can just remove the overrides.

I will try and add that tomorrow. Thanks for the input.

0 Likes

#7

Alright @iamntz, got your change in.

So now you can define these default parameters:
[pre=#2D2D2D] // Global defaults to use if a bracket does not define its own
“default_icon”: “dot”,
“default_style”: “underline”,
“default_color”: “brackethighlighter.default”,[/pre]

And then you can have a bracket pick up using them by removing there override paramater. So for example, If I have a curly bracket that I want to pick up the default color and style, I would simply just remove the override parameters like in the example below:

[pre=#2D2D2D] // Basic brackets
{
“name”: “curly”,
“open”: “(\{)”,
“close”: “(\})”,
“icon”: “curly_bracket”,
// “color”: “brackethighlighter.curly”,
// “style”: “underline”,
“scope_exclude”: “string”, “comment”],
“scope_exclude_exceptions”: “string.other.math.block.environment.latex”],
“language_filter”: “blacklist”,
“language_list”: “Plain text”],
“find_in_sub_search”: true,
“ignore_string_escape”: true,
“enabled”: true
},[/pre]

This way allows you to change the default, and all the brackets pick up the change if they haven’t overridden the defaults.

0 Likes

#8

Thanks for the update. Seems to work good, although i was talking about some kind of master switch, but it’s ok afterall. I guess :smiley:

How do i change highlight colours though? I have this in my thTheme file but nothing happen (also restarted the editor)
(http://img.iamntz.com/jing/2012-10-23_1623.png)

(i have no idea if i set up the old colours or was default to that beautiful green :smile: )

Thanks!

0 Likes

#9

@iamntz

So you wanted like a force_default_style_use switch? I can add that as well if you like. Just let me know.

Yeah, ST2’s configuration of region colors is kind of lame, so it makes it that much more confusing.
It looks like you are using Monokai, so doing nothing in the old version would yield green. That is because the default for the old BH was "entity.name.class"
So if you change your default to “entity.name.class”. And make the rest pick it up, you should get green.
[pre=#2D2D2D] // Global defaults to use if a bracket does not define its own
“default_icon”: “dot”,
“default_style”: “solid”,
“default_color”: “entity.name.class”,[/pre]

Or you can define it in the bracket definition:
[pre=#2D2D2D] // Quotes
{
“name”: “pyquote”,
“open”: “u?r?((?:”")?"|(?:’’)?’)",
“close”: “((?:”")?"|(?:’’)?’)",
“icon”: “quote”,
“color”: “entity.name.class”,
“style”: “underline”,
“scopes”: “string”],
“language_filter”: “whitelist”,
“language_list”: “Python”],
“sub_bracket_search”: “true”,
“enabled”: true
},[/pre]

In order to configure it via the theme file, you have to use the entire scope. By default I am using the scope namespace of “brackethighlighter”, so that must be included as well. Here is an example from mine.
[pre=#2D2D2D]
name
Bracket Curly
scope
brackethighlighter.curly
settings

foreground
#CC99CC



name
Bracket Round
scope
brackethighlighter.round
settings

foreground
#FFCC66

[/pre]

I hope that makes sense.

0 Likes

#10

Totally make sense! Thanks, works just beautiful!

The force_default_style switch would be nice, but wait for others and see what’ they says to not work only for one crazy dude :wink:

But a nice switch to add would be a default color. Because adding 15 entries in tmTheme that set the very same color it might be slightly… wrong?

0 Likes

#11

[quote=“iamntz”]Totally make sense! Thanks, works just beautiful!

The force_default_style switch would be nice, but wait for others and see what’ they says to not work only for one crazy dude :wink:

But a nice switch to add would be a default color. Because adding 15 entries in tmTheme that set the very same color it might be slightly… wrong?[/quote]

It is only wrong if you don’t want different colors. The scopes in the settings file right now are really on examples. BH2 does not require a user to add anything to the theme file, or even use those scops, that is an option that is available for those who want absolute control of their color (like I do). By default, I set each to scopes that don’t exist in most themes, which will default to a the foreground color. If a user would like to define those, or use something different, they are welcome to it. Since the plugin is still in development, the settings file reflects what I have been doing in testing.

I realize because I am defining a number of different scopes in the settings file, a user will feel they need to add these to the themes. I will push out an update later that will simply define them all to “brackethighlighter.default”. Then if some one wants a different colors for a specific brackets, they can define it and change it to whatever they want. The settings file is just a suggestion. Ideally people will just copy it to their user folder and tweak it to there liking.

0 Likes

#12

Great update!!! :smile:
Havent checked the options in detail but played around with Ruby brackets marking.


after that updated the open pattern to
[pre=#212121] “open”: “^\s*\b(if|until|while|begin|class|module|def\s*[a-zA-Z_]+)\b”,[/pre]
but then how do i define new pattern to match do-end block as in


if i define new bracket definition as simple as
[pre=#212121]{
“name”: “ruby”,
“open”: “\b(do)\b”,
“close”: “\b(end)\b”,
“icon”: “dot”,
“color”: “keyword”,
“style”: “underline”,
“scope_exclude”: “string”, “comment”],
“language_filter”: “whitelist”,
“language_list”: “Ruby”],
“enabled”: true
},[/pre]
if it’s placed before default definition then do-end blocks get matched but all other defined with open pattern above fail, and on the flip side if i define this after default definition then do-end blocks are not matched.
i guess it’s because both definitions share the same close pattern.

0 Likes

#13

[quote=“vitaLee”]Great update!!! :smile:
Havent checked the options in detail but played around with Ruby brackets marking.
[attachment=1]Screen shot 2012-10-23 at 19.58.50.png[/attachment]
after that updated the open pattern to
[pre=#212121] “open”: “^\s*\b(if|until|while|begin|class|module|def\s*[a-zA-Z_]+)\b”,[/pre]
[/quote]

Cool, I will update that.

[quote=“vitaLee”]
but then how do i define new pattern to match do-end block as in
[attachment=0]Screen shot 2012-10-23 at 20.08.28.png[/attachment]
if i define new bracket definition as simple as
[pre=#212121]{
“name”: “ruby”,
“open”: “\b(do)\b”,
“close”: “\b(end)\b”,
“icon”: “dot”,
“color”: “keyword”,
“style”: “underline”,
“scope_exclude”: “string”, “comment”],
“language_filter”: “whitelist”,
“language_list”: “Ruby”],
“enabled”: true
},[/pre]
if it’s placed before default definition then do-end blocks get matched but all other defined with open pattern above fail, and on the flip side if i define this after default definition then do-end blocks are not matched.
i guess it’s because both definitions share the same close pattern.[/quote]

Right now, it would have to be included in your original Ruby pattern. This is simply something I didn’t think about. They are combined in one regex (each bracket definition should only have one capturing group), that group id is used to identify what pair the brackets are from. Then I resolve all of the brackets until I find the matching pair.

There is kind of a way around it, but it would require a bracket plugin. I may try and in some additional support for such cases in the future, but I will post a way you can resolve this with a plugin as a stop gap solution.

0 Likes

#14

missed unless
[pre=#212121]“open”: “^\s*\b(if|unless|until|while|begin|class|module|def\s*[a-zA-Z_]+)\b”[/pre]

0 Likes

#15

@vitaLee, try this: this will make all ruby keywords underlined, but do will be outlined.

Put this in your User folder for now as rubykeywords.py
[pre=#2D2D2D]def post_match(view, name, first, second, center, bfr, threshold):
bracket_name = “rubydo” if bfrfirst.begin:first.end] == “do” else name
return first, second, bracket_name[/pre]

Define “do” in the original ruby, and create a “rubydo” after that as seen below.
[pre=#2D2D2D] // Ruby conditional statements
{
“name”: “ruby”,
“open”: “^\s*\b(if|until|while|begin|class|module|do|def\s*[a-zA-Z_]+)\b”,
“close”: “\b(end)\b”,
“icon”: “dot”,
“color”: “keyword”,
“style”: “underline”,
“scope_exclude”: “string”, “comment”],
“plugin_library”: “User.rubykeywords”,
“language_filter”: “whitelist”,
“language_list”: “Ruby”],
“enabled”: true
},
{
“name”: “rubydo”,
“open”: “^\s*\b(do)\b”,
“close”: “\b(end)\b”,
“icon”: “dot”,
“color”: “keyword”,
“style”: “outline”,
“scope_exclude”: “string”, “comment”],
“language_filter”: “whitelist”,
“language_list”: “Ruby”],
“enabled”: true
},[/pre]

You can extend this concept to break out as many as you want. I do assume that if too many separate kinds of brackets are defined for one sytntax file, that you could theoretically hit a limit, but even if you split all of the ruby keywords into their own separate one, you probably wouldn’t hit it.

Hopefully in the future I can fix it so that BH will be smart enough to resolve these kinds of things without the need of a plugin.

0 Likes

#16

That is a little trick I am doing right now for angle brackets and tags.

0 Likes

#17

i kinda get what you mean but i think it wont work because as i understand, for this to work rubydo’s open pattern should be a subexpression of it’s predecessor’s open pattern.
but do will always be preceeded by more than just whitespace and not anchored to bol.
not sure if i got it right, but can you try to match this do-end with your solution

[pre=#212121]3.times do |i|
puts ‘hip hip!!!’
end[/pre]

0 Likes

#18

Would it make more sense to separate styles from bracket definitions?

For instance, you have some definition pointing to a style object (in this case a style object called “ruby”):
[pre=#2D2D2D] // Ruby conditional statements
{
“name”: “ruby”,
“open”: “^\s*\b(if|unless|until|while|begin|class|module|do|def\s*[a-zA-Z_]+)\b”,
“close”: “\b(end)\b”,
“style”: “ruby”,
“scope_exclude”: “string”, “comment”],
“plugin_library”: “User.rubykeywords”,
“language_filter”: “whitelist”,
“language_list”: “Ruby”],
“enabled”: true
},[/pre]

And then you have style objects:
[pre=#2D2D2D] “styles”: {
“ruby”: {
“icon”: “dot”,
“style”: “underline”,
“color”: “brackethighlighter.ruby”
},
“rubydo”: {
“icon”: “dot”,
“style”: “underline”,
“color”: “brackethighlighter.rubydo”
}
// More styles here…
}[/pre]

That way you could have one definition and then define many other styles. A post match plugin could simply throw back a style, and you wouldn’t have dummy regex clogging up the system.

What do you guys think?

0 Likes

#19

[quote=“vitaLee”]i kinda get what you mean but i think it wont work because as i understand, for this to work rubydo’s open pattern should be a subexpression of it’s predecessor’s open pattern.
but do will always be preceeded by more than just whitespace and not anchored to bol.
not sure if i got it right, but can you try to match this do-end with your solution

[pre=#212121]3.times do |i|
puts ‘hip hip!!!’
end[/pre][/quote]

Oh, I see that is tricky. Let me think about that some more.

0 Likes

#20

I cannot be stopped :smile:. Try this:

User/rubykeywords.py
[pre=#2D2D2D]import re

def post_match(view, name, first, second, center, bfr, threshold):
open_bracket = bfrfirst.begin:first.end]
if open_bracket != “do”:
m = re.match(r"^(\s*\b)\w\W]*", open_bracket)
if m:
first = first.move(first.begin + m.end(1), first.end)
return first, second, name[/pre]

And lastly the bracket define (only one is needed now)
[pre=#2D2D2D] // Ruby conditional statements
{
“name”: “ruby”,
“open”: “(^\s*\b(?:if|until|unless|while|begin|class|module|def\s*[a-zA-Z_]+)|do)\b”,
“close”: “\b(end)\b”,
“icon”: “dot”,
“color”: “keyword”,
“style”: “underline”,
“scope_exclude”: “string”, “comment”],
“plugin_library”: “User.rubykeywords”,
“language_filter”: “whitelist”,
“language_list”: “Ruby”],
“enabled”: true
},[/pre]

This shows how flexible it is :smile:.

0 Likes

#21

I will make the ruby post_match plugin official. If this works good for you.

0 Likes

#22

Man, you’re tireless. :smiley:
It’s working.
Im sure there’ll be other exotic problems to solve with ruby being expressive as it’s, but you clearly prooved the flexibility of BH2.

0 Likes

#23

you might want to update open pattern to
[pre=#212121]“open”: “(^\s*\b(?:if|until|unless|while|begin|class|module|def\b\s*[a-zA-Z_]+)|do)\b”[/pre]
to account for this side effect

Also i vote 1+ for styles extracted and reused across definitions.

0 Likes

#24

[quote=“vitaLee”]you might want to update open pattern to
[pre=#212121]“open”: “(^\s*\b(?:if|until|unless|while|begin|class|module|def\b\s*[a-zA-Z_]+)|do)\b”[/pre]
to account for this side effect
[attachment=0]Screen shot 2012-10-23 at 22.42.21.png[/attachment]
[/quote]

Great! Thanks for your help on this. I haven’t coded in ruby so it is nice to have help nailing it down.

[quote=“vitaLee”]
Also i vote 1+ for styles extracted and reused across definitions.[/quote]

That is the good thing about this being an alpha; in an alpha I can change everything and say “I told it you it was an alpha”. Beta I don’t have that much flexibility. I am thinking it would make more sense with separate style objects. I will have to see how much I have to change in the algorithm to make that happen. I will see if anyone else chimes in as well.

0 Likes

#25

Ruby fixes are in.

Still tinkering with the styles. Separating the styles doesn’t really reduce the number of style stuff by much, it just puts it in a separate place. The regions are made up of the whole combination of icon, color, and highlight style, so they really need to be one package. So even if you use the same color and highlight style, having different icons still means having separate style objects. And I really don’t think I am looking for an overly complicated styling system either. I will play with it in the next couple of days, and hopefully role something out. I think the separation is good, I just don’t think its going to amount to great reduction of stuff in the config file.

That is how it goes though; you want something highly configurable, sometimes the downside is you have to configure that stuff every time.

0 Likes