GNOME Bugzilla – Bug 307048
Smart block and brace matching
Last modified: 2016-08-11 06:27:53 UTC
In the following examples, I am using '|' to denote the insertion point. When entering an opening bracket as follows: func_name(| ...the widget should insert a matching closing brace, while leaving the insertion point INSIDE the bracket pair so as to allow specification of parameters: func_name(foo, bar|) Once parameters have been specified, pressing enter should move the insertion point out of the bracket pair: func_name(foo, bar)| Pressing enter again should move the insertion point to the new line as normal. func_name(foo, bar) | In the case of multi-line blocks, typing the opening brace and pressing enter: func_name(foo, bar) { | ... should result in a matching closing brace being inserted on the line following the line of insertion, as well as auto-indentation: func_name(foo, bar) { | } Perhaps there could be a keyboard shortcut named Next Block or something similar that would move the insertion point out of the current block and into the next available one: func_name(foo, bar) { } | Since some languages use whitespace and indentation to define blocks, while others use "begin...end" or "def funcname...end", there would need to be a way to define the beginning and end of single-line and multi-line bracket/brace pairs. The same architecture might be used for XML opening/closing tag and processing instruction completion, as well as multiline comment completion (think "/*" and "*/", or "<!--" and "-->"). Also, logic structures like "if...else...end" could benefit.
*** This bug has been marked as a duplicate of 107044 ***
This is not a duplicate of 107044, which is soley concerned with auto-indentation. This bug is about smart brace matching and insertion point movement. While resolving this may be out-of-scope for gtksourceview, it should still be treated separately and not tossed in with a bug that has only a slight amount of overlap. Please close this RFE if it is indeed out of scope for the gtksourceview widget, but this is not a dupe.
This is a duplicate of both bug #672800 and bug #736727.