Implement GoToBrace action in the VS editor
https://www.xsharp.eu/forum/topic?p=30411#p30411
I know in Visual Studio there is syntax highlighting that matches things like if/for/while statements and highlights it. This is great for small containing statements where it is easy to see but in larger methods that may have multiple return statements or an If..ElseIf..Else..EndIf that goes off screen, it can be difficult to see the bigger picture or tap along to the next section of code. In Visual Studio they have a keyboard command called "Edit.GoToBrace". This seems to be defaulted to "Ctrl + ]" in my system and it allows me to click on a brace and jump to its matching brace. This works in c#, but not in X# currently.
Implemented in b597b768edec6ae80abd3de73834865d98ee32a0
It works now, but with some hiccups:
-
Go to brace does not work for brackets, parentheses etc, shouldn't it cover those as well?
-
Put the caret on the ENDIF keyword below and do GotoBrace, caret moves to the IF keyword, good. Now choose it again, it moves to ENDIF correctly, but the caret is placed at the end of the word, ENDIF does not get highlited and a new GotoBrace doesn't do anything. Same happens if you start with "ELSE", caret moves to end of "ENDIF" and no further GotoBrace is possible, unless you use the left arrow button to put the caret "inside" the ENDIF keyword.
FUNCTION Test() AS VOID
IF TRUE
NOP
ELSE
NOP
ENDIF
aRet := { 1, IIF(TRUE,1,2) , 2, a[123] } // no go to brace on () {} and []
It's better now, but not perfect and has a new issue. Now GotoBrace from a "middle" keyword (ELSE, ELSEIF, CATCH etc) doesn't get you to the respective END anymore, but instead puts the caret in the second to last letter of that middle keyword. So gets you to "I" of ENDIF, "T" of CATCH etc.
Also going from IF to ENDIF, puts the caret on "I" of ENDIF. Technically not wrong, but it does not feel nice, I would expect the caret to go to the beginning of ENDIF, just before the "E". Going from ENDIF to IF works fine, gets you to the beginning of "IF". Same issue exists for all other block statements, like TRY, DO WHILE etc.
Of course not a showstopper, but...
Confirmed fixed