Matching brackets near golang channel operators doesn't work

[arsham]

Summary

With golang code, where channel receivers are defined inside a block, the matching brackets functionality doesn't work. Channel are first class objects in go and their operator is <- that can land wither side of a channel variable.

Expected behavior

Expected to travel between two brackets as normal.

Actual behavior

It only matches the ending bracket or nothing at all depending where you put your cursor.

Steps to reproduce

1. First step With this code snippet:

{
    if true {
        a := <-someChannel // this means it receives a value from a channel
    }
}

2. Second step Place the cursor on if statement and hit ctrl+m.

3. Third step Place the cursor under if statement on an empty space and hit ctrl+m.

Environment

• Operating system and version:
  • Linux (archlinux latest)
• Sublime Text:
  • Build 3126

[keith-hall]

This seems to work fine in my testing on Windows and Linux (Ubuntu 16.10).

[arsham]

That is correct. However I just discovered if you set this value in settings it doesn't work anymore:

    "match_brackets_angle": true,

Also it makes sense, because that character is affected by this settings. Feel free to close this issue if it is not possible to have ST ignore that settings on non-HTML contents.

Thank you

[keith-hall]

Thanks for the update, I can confirm the same with "match_brackets_angle": true set. I believe ST should be able to use the scope to determine whether it is an operator (for which it should not attempt to match brackets) or punctuation (for which it should attempt to match brackets), so I think it could potentially be fixable this way.

[jtojnar]

Same happens in Rust:

fn foo<T: Foo + Fn(u32) -> Result<bool, u16>>(_foo: PhantomData<T>) -> () {
    if 4 < 5 {
        // something
    }

    // Place cursor here, press ctrl-M
    println!("Place cursor");
}

impl<T: Debug> Foo<T> where
    T: Borrow<u32> {
    fn test() {
        foo::<test>();
        println!("{}", <i32>::MAX);
    }
}

As far as I could tell, we only need to consider matching the brackets that are in the following scopes:

• source.rust meta.generic.rust punctuation.definition.generic.begin.rust
• source.rust meta.generic.rust punctuation.definition.generic.end.rust