Shouldn't prevent inserting closing pair after caret leaves the block

[pintassilgo]

if (/\s/.test(str) {
  return;
}

Let's say I have this bad JS code. It's missing a ) in first line. If I place caret after str and press ), it should print this char, so that line ends with )) { so that code is good. VSCode works as expected. But Cuda just moves caret to the right, keeping just one ).

Suggested way to handle this:

• Inserting a closing pair should only be skipped while caret was always inside this pair block since its auto insertion. And also at the same line of the closing pair.

So, for instance, if I type in a new line if (, Cuda will insert the closing pair ) next to the cursor, then I type the condition expression, then press ), Cuda doesn't insert it because it was already there: correct. But once user moves caret out of the block, for instance if they place it in other line, then moves it back, Cuda shouldn't prevent the typing of ).

I guess that's exactly how VSCode behaves.

[Alexey-T]

2 arguments against this

1. Sublime does it like Cud.
2. adding this needs some memory for previous input. so it's more hard to code this feature. also: work of the bracket typing will be different depending on memory state: when memory 'allows' to insert, when not. and when 'allows', I can reopen file, move caret up/down, and then Cud 'disallows' to insert bracket? bad!

[pintassilgo]

1. Some things Sublime does better, some things VSCode does better, some things Cuda does better. In this case, VSCode does it better, it's smarter, it makes sense to behave as it does.
2. It's similar to the "pair brackets finder" (or whatever be its name), with the difference of storing a flag while "caret had never left this pair block". As soon as caret leaves the block for the first time (or move to a different line), the memory state can be deleted and that means editor shouldn't prevent inserting a closing pair.

I can reopen file, move caret up/down, and then Cud 'disallows' to insert bracket? bad!

Sorry, but I don't understand your example. It's like the opposite. Currently, Cuda always "disallows" to insert closing pair if that closing bracket is already the char at the right of the caret. Look at this code: ((|). Copy it, paste in Cuda, replace | by caret position then press ). Cuda (and Sublime) will not insert the char, will just move caret to the right. VSCode, on the other hand, inserts the second closing pair. For me it's obvious VSCode is the one doing it right.

When there is a closing pair at the right of caret, that usually means the user had just opened the pair and the closing char was auto added by the editor, so typing the closing char should be blocked in a continuous writing sequence to avoid unwanted duplicates. But VSCode is smarter to understand that once caret lefts this pair block, this "continuous writing sequence" was interrupted so it no longer makes sense to skip the printing of the pressed char.

[Alexey-T]

I reconcider this feature-request.
tried to add it. not equally to VScode but similar (did not check caret leaving the original block of '()', checked only caret leaving original line).
note: did it for single-caret only.
you may want to test mul-caret case and give suggestions what to do.

beta linux-qt5:
cudatext.zip

[pintassilgo]

Thanks, at first sight it's working as expected. I hardly use multi-caret when coding, but I guess it's fine for this feature to only work for single caret. The only improvement I can see is if someday you can make it like VSCode, but it's already better now.