Open ndac-todoroki opened 3 years ago
I rethought about this...
Maybe we can just make the opening
closing
options to match strictly by the word boundary, like the \b
anchor in regexp.
# given settings as `"word": [ { "opening": "do" } ]`
def foo do # <- matches
...
end
def foo, do: ... # <- does not match, because `do:` is not `do` when regexp is /\bdo\b/
This should not be enabled on symbol brackets, because then this kind of troubles occur:
public static main(int i; //<- will not match
return null;
)
But when using word brackets, I don't think anyone (any language) wants do
s and end
s to work without a word boundary.
First, thank you for suggestions!
But I'm not sure about this.
This should not be enabled on symbol brackets, because then this kind of troubles occur:
public static main(int i; //<- will not match return null; )
Isn't it the behavior due to the bracketLens.minBracketScopeLines
option?
Ah no, I meant that if you force to match symbol brackets by word boundaries too, like /\b\(\b/
, then that opening bracket in the example above won't match (which should be detected).
日本語OKだったことに気づいたので日本語で書きます(説明難しかったので) symbol bracketの場合に単語境界を必須にしていると、上の例のような変な改行位置ではあるが有効なコードである場合に正しくパースできなくなってしまう気がしまうので、word bracketだけ単語境界を見るようにしてほしいです、という話でした!
Problem
When there are single lined
do...end
block inside Elixir code, bracket-lens cannot parse brackets correctly.Examples
In the valid Elixir code below, brackets aren't correctly detected:
What is happening
def zip
is judged to be insidedef bar(null)
'sdo
block.Configuration
Thoughts
In Elixir,
do...end
blocks are syntax sugar of[do: term]
keyword lists, which could be written without brackets.These are all the same.
If my settings are not wrong, maybe we need a "ignore" option to ignore
do:
s.