First of all, I apologize for the word "brace" applied to "parenthesis". I was aware about the difference, but, I kept Genay's terminology: _"Goto matching brace - Ctrl-B. If the cursor is ahead or behind a brace, then it is moved to the brace which belongs to the current one. If this keyboard shortcut is pressed again, the cursor is moved back to the first brace."_ I will comment on the sentence **_"If this keyboard shortcut is pressed again, the cursor is moved back to the first brace."_** later. > "Since braces do not commonly occur consecutively, the current Geany > algorithm works correctly without saved state[0] and returns the cursor to > its original position after two "goto matching brace" commands."
In general I agree with it. Although there is unformatted javascript code with nested anonymous functions when curly brackets widely occur consecutively, and bracket matching is useful. (BTW, many languages do not curly brackets, but parentheses are part of almost every language. ) > "However non-brace brackets also commonly do not enclose as much code as > braces do" Here I disagree. Not only in Lisp. :) Just two common cases: 1) The corporate systems of many financial, insurance and telecommunications corporations have complex business rules. Initially, developers rarely invested in the elegance of the code. In addition, when changing business rules, developers often try to minimize changes in very old code. Thus, the Boolean expressions in the “IF” statements become horrible and easily take up a lot of screens. 2) Very often, SQL scripts have several-screen expressions. SQL formatting is always problematic because the canonical formatting by using tools easily turns several-screen statement into dozens of screens, that is impractical. Consecutive occurrence of parentheses is very common. > "and so the highlighted matching bracket is visible, making goto less useful > for non-brace brackets" I disagree and agree at the same time. When I looked again at "matching" implementations in other GUI editors, I noticed that the highlighted brackets are really perfectly visible. The problem is that Geany doesn't highlight brackets, but only colors them. Like SciTE, Geany, use blue color, which is not very contrasted. Notepad++ is doing slightly better, it colors in red, but even red color cannot be compared with the highlighted symbol. It's almost impossible to find a colored bracket on multiple screens the help of software. That's why I hit double "goto" on a regular basis. Jumping to wrong brackets affected my performance. A few years ago, I wrote a simple LUA script for SciTe. I recently moved it to Geany's LUA. Why did I start this topic if my simple script is great for my needs? Only two reasons: 1) Personally I would also "have chosen the following pair". This behavior cannot be changed by LUA. ( Maybe a plugin could do it). 2) I definitely prefer to get the right functionality out-of-the-box than than download any additional fix later. > "It is inappropriate to break the useful behavior of the important use-case > to correct behavior in the less important use-case." I am confused a little by the meaning of the "breaking the useful behavior" expression. If you mean support of incorrect behavior in a dubiously less important usage scenario, in order to save on an extra key press when the starting position was on the “wrong” side, then I have no arguments. However, I still believe that the original idea of the current behavior was not to preserve the unimportant side of the bracket, but to control the quick selection of the enclosed text: include brackets or not include brackets. At least this goal really makes sense. However, this is not critical for performance, and it can be easily achieved by applying two different commands instead of a combination when one command performs an action differently according to the position of the cursor, but in “less important” cases the command does wrong. Also, I do not see much sense in logic when the sequence “goto + goto” moves the cursor to one side of the bracket, and “goto + left arrow + right arrow + goto” moves to the other side. Finally, I would suggest something else. Geany has a very detailed manual. I would suggest removing the sentence **"If this keyboard shortcut is pressed again, the cursor is moved back to the first brace."** or indicating when it will do it, and when will not. Users should not be misinformed. Right? :) -- 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-477708113
