Bug 370716 - Automatically overwrite closing brackets
Summary: Automatically overwrite closing brackets
Status: CONFIRMED
Alias: None
Product: kdevelop
Classification: Applications
Component: general (show other bugs)
Version: 5.0.1
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-13 22:40 UTC by Janek Bevendorff
Modified: 2019-06-10 09:49 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Janek Bevendorff 2016-10-13 22:40:48 UTC
This is a feature which all JetBrains IDEs (IntelliJ IDEA, CLion, PyCharm etc.) have and which is super useful and makes working with automatically inserted closing brackets a lot more fun.

When I type something like

void foo(int bar|)

(with | showing the current cursor position and the closing bracket automatically inserted), I usually need to move my finger to the right arrow key to skip the closing bracket. However, in IntelliJ I can simply type ")" instead which does the same, so I have

void foo(int bar)|

In KDevelop, however, I end up with

void foo(int bar)|)

Would be great if this could be implemented. This also makes it easy to not get lost in too many consecutive closing brackets, because you simply type ")" until the editor tries to insert a new one and then you know you reached the end (which isn't always obvious just with highlighting).

Reproducible: Always
Comment 1 Sven Brauch 2016-10-13 22:45:35 UTC
For kate's autobrace, this is already the case, under certain conditions.

For KDevelop's autobraces, hmm, I don't know how simple it is to do this technically. Not so simple, I think.

I'm actually considering to rework how autobraces work in kate, i.e. just "eat" closing parentheses iff the result of inserting a new character would lead to there being more closing than opening parentheses in the current line. Would that help?
Comment 2 Janek Bevendorff 2016-10-13 22:52:33 UTC
I think that's what IntelliJ does. It always "eats" the braces and
brackets as long as there are corresponding opening ones. It doesn't
care if they were already there, just typed by the user or inserted
automatically.
Comment 3 Sven Brauch 2016-10-13 22:58:09 UTC
Ok, that would solve your original request as well. I'll implement that and talk it over with the kate devs.
Comment 4 Janek Bevendorff 2016-10-13 23:06:40 UTC
I have to say, there are some corner cases where bracket eating has already annoyed me in IntelliJ. This is mostly, when revising brackets within brackets. But generally, this happens a lot less and is a lot less annoying than always ending with excess brackets because I'm too lazy to move my hand over to the arrow keys.
Comment 5 Sven Brauch 2016-10-14 21:59:53 UTC
That is the problem, yes. That's why current KTextEditor only eats closing parentheses when you did not move your cursor out of the range between the two parentheses before typing the closing one.

Maybe we can insert the () from KDevelop by simulating typing "(" if autobrace is enabled. Then that would work here, too ...
Comment 6 Janek Bevendorff 2016-10-14 23:25:13 UTC
It somehow also doesn't eat brackets when a new pair has been inserted
within. So foo(bar(|)) will result in foo(bar())|) when typing ")"
twice. The inner bracket is overwritten, but the outer bracket is not
which is super annoying.

Generally, I don't think it would be a problem to just consume any
closing brackets as long as they have a corresponding opening bracket.
You can a lot more than you lose.
Comment 7 Sven Brauch 2016-10-14 23:30:53 UTC
True yes, that should be a stack of saved ranges, not just one.

The other issue with what we're thinking about is that "has a corresponding opening bracket" is a highly nontrival concept. What does that mean? Within the same line? In the whole document? Do comments count? Do strings count?
Comment 8 Janek Bevendorff 2016-10-16 12:01:46 UTC
It should have the same logic as the already existing bracket
matching/highlighting.
Comment 9 Matt Whitlock 2017-09-14 15:12:30 UTC
(In reply to Sven Brauch from comment #7)
> The other issue with what we're thinking about is that "has a corresponding
> opening bracket" is a highly nontrival concept. What does that mean? Within
> the same line? In the whole document? Do comments count? Do strings count?

See my comments in Bug 368580 for a proposed solution that avoids this issue entirely.
Comment 10 FeepingCreature 2018-03-28 22:36:36 UTC
This bug is horrible. It makes code completion practically unusable. It would literally be better to never insert a closing bracket at all.
Comment 11 Diggory Hardy 2019-06-10 08:51:48 UTC
In Kate 18.12.2, I can got to an existing line like

fn main() {

then insert the cursor between the brackets and type ')'. Result: the cursor is moved one space to the right (with or without the 'enable automatic brackets' option).

This behaviour happens even if I just added another bracket! E.g. typing 'x: (f32, f32)' results in:

fn main(x: (f32, f32) {

(missing closing ')' because the old one was overridden).

I'd been wondering why the compiler has complained about missing brackets so much lately. This behaviour is horrible (personally I prefer no autocompletion).
Comment 12 Christoph Feck 2019-06-10 09:49:59 UTC
Comment #11 is bug 407852.