match_brackets_angle

[MasonRemaley]

I just set "match_brackets_angle" to true locally and it's making writing Rust code with lots of generics a lot easier, I never really noticed before but it defaults to false and that's probably why I always tend to get the angle brackets mismatched, I assume others have this issue too.

Would it make sense to set that as a default in this package, or is this not the right place to do that sort of thing? I started to make a PR, but noticed that all the other defaults set in RustEnahanced.sublime-settings were for settings actually created by this package.

[dten]

Does this mess with a simple <, meaning whilst generics are easier maths is more annoying? If yes then the option is there for those who want it, not sure it should be default.

[dten]

oh i tried it. it's only for highlighting (i thought it was gonna auto insert the end)? it is a little odd seeing it matching things like the below, where the < matches the the > of the =>

match n {
	_ if n < 1000 => {
		undefined!()
	},
}

in general though it's nice (think i'm leaving it on)

[MasonRemaley]

I was wondering the same thing about gl/lt, but so far haven't come up with any cases where it causes any real issues--that case above does get highlighted for me even though it shouldn't, but if you get rid of what it considers the opening brace it doesn't like make the opening closing out of sync for everything else and mess up other highlighting or anything.

[ehuss]

I've discovered a case where this does cause an issue. I often use ctrl+m to jump between brackets, but the => in a match prevents you from jumping forward:

fn f() { // ctrl+m here fails
    match x { // ctrl+m here fails
        pattern => {
            
        }
    }
}