[Github-comments] [geany/geany] A problem with "go to matching brace" command. (#1998)

[elextr]

@dyura there is a bug here, as the label says, so it shouldn't be closed.

To summarise the TL;DR for future bug fixers:

1. If the vertical bar cursor is between a bracket and a non-bracket, the bracket is selected for highlighting irrespective of which side the cursor is on, if the cursor is between two bracket characters the one before the cursor is chosen to be highlighted.

2. The `goto matching brace` goes to the bracket matching the highlighted one.  This is particularly useful for braces `{}` in C class languages where they enclose blocks of code and the matching brace is commonly off screen.  It is less useful for non-brace brackets where they commonly enclose less, and the matching highlighted bracket is therefore visible on screen without goto, so goto is less needed for non-brace brackets in those languages.

3. If the cursor was originally outside the bracket, goto places it outside the matching bracket and if it was inside it is placed inside the matching bracket.  This provides a useful feature that two `goto matching brace` commands will return the cursor to the original position.

The combination of 1. and 3. causes a bug when the target position is inside the matching brace because of 3. but also happens to be between two consecutive brackets.  In this case the bracket after the cursor is the intended matching one, but 1. causes the bracket before to be highlighted, so highlighting the wrong "matching" bracket and also meaning the next goto will go to the wrong place.

As noted in 2. the most useful use-case for goto is in braces enclosing code, and there the common code layout rules of placing braces on lines by themselves means the bug rarely manifests in this use-case.

So the challenge is to fix the bug in the less commonly useful use-case without breaking the useful feature of returning to the original position in the commonly useful use-case.  

It is likely (IMHO) that the return feature will need to be implemented with some internal state instead of recording the previous position in which side of the target the cursor is placed, but someone may find a better solution.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/1998#issuecomment-485189555
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20190420/2fde8c4d/attachment.html>