>>> No. My specification was (and I quote): "skip over the auto-inserted part". Not "always ignore a typed paren if there happens to be one at the cursor".
>>
>> Well, in normal 99% usage, it does skip over the auto-inserted part.
>> I get what you're saying, I just can't believe you consider such a
>> strange and rare case a deal breaker.
>
> Sorry, but I must chime in.
> This is not rare, at least for me.
> I had other editors that did it like you suggest
> (for example RStudio) and it is annoying; it
> has this 'hey, I am way smarter than you ;)' attitude
> wich gets very annoying over time

I know what you're talking about, which is why I'm surprised anyone
would want to try to make it even smarter than it already is.  Right
now, the user can simply look at what text is at the cursor and, from
that, ascertain the behavior that pressing the next key will evoke.

With what is being proposed by Bert, the user will now have to examine
the full nesting, count the parentheses and brackets, maybe check the
leading character, etc. to understand why it did, or did not, insert
their closer character.  The whole purpose of Auto Enclose (et al) is
to relieve the user from ever having to go through this tedious
exercise.

And what about when their expressions will get out-of-balance?  Will
the system handle that "perfectly" and how will the user understand
what happened when they typed a character and the system didn't behave
like they thought because it was so complicated.

I think we're in agreement about what we want the user experience to
be, I just think we totally disagree about how it should be provided.

>> Why?  Maybe you could provide 1 example from the image where you feel
>> typing that method with Auto Enclose wouldn't perform to your
>> specification or otherwise be a terrible nuisance compared to with it
>> turned off.  How many methods in the system present such a challenge?
>> For every 1 you find, I bet can I find 10 (or 100!) where it does meet
>> your specification ("skip over the auto-inserted part") and therefore
>> overall better to enjoy the benefits of Auto Enclose turned on.
>
> See: code I have ( | is cursor )
>

1 >  self foo: (knorz bar: max)              "ah, there is something missing"
2 >  |self foo: (knorz bar: max)             " ... "
3 >  c add: |self foo: (knorz bar: max)      " oh, that now needs parens "
4 >  c add: ()|self foo: (knorz bar: max)    " ARGH "
5 >  c add: (|self foo: (knorz bar: max)     " Backspace "
6 >  c add: (self foo: (knorz bar: max|)     " maybe an off by one? add +1 "
7 >  c add: (self foo: (knorz bar: max + 1|) " Ohm a closing paren
still missing. I now type )"
8 >  c add: (self foo: (knorz bar: max + 1)| "  ARGH "

This is a good working example, thanks, let's look at this together (I
added line numbers for reference).

At line 4, the cursor is actually between the parens, like this:

    c add: (|)self foo: (knorz bar: max)

I understand your ARGH at line 4, but there's a problem with the one
at line 8.  Because this user is starting to work on their /next/
expression (max+1) before they finished their /current/ expression (c
add: (self foo: (knorz bar: max))).  Maybe you have a "dual-core"
brain where mine is only a single-core, because I think a normal user
would not do that.  I think users who are trying to work on multiple
expressions at once are the ones who will most benefit from Auto
Enclose.  IOW, just for clarity, here is the process a normal user
would follow:

0 > self foo: (|)                                     "ah, the system
typed the closing paren for me, NICE!"
1 >  self foo: (knorz bar: max)              "ah, there is something missing"
2 >  |self foo: (knorz bar: max)             " ... "
3 >  c add: |self foo: (knorz bar: max)      " oh, that now needs parens "
4 >  c add: (|)self foo: (knorz bar: max)    "ah, the system saved me
a keystroke at 0, so I understand why it did this, is there a better
way?"
5 >  c add: (|self foo: (knorz bar: max)     "Delete"
5.1 > c add: (self foo: (knorz bar: max)|   "End key"
5.2 > c add: (self foo: (knorz bar: max))|   "Closing paren.
Expression modification completed.  Next?"
6 >  c add: (self foo: (knorz bar: max|))     "maybe an off by one? add +1 "
7 >  c add: (self foo: (knorz bar: max + 1|)) "Ohm a closing paren
still missing. I now type )"
8 >  c add: (self foo: (knorz bar: max + 1)|)  "System did not insert
an additional paren, NICE!"

So, that leaves your ARGH at line 4 but because of what happened at 0,
the user probably understands what and why it happened.  So instead of
saying "ARGH" I think they might be more inquisitive to ask, "Is there
a better way?"  Which, of course, there is:

3 > c add: |self foo: (knorz bar: max)   "Press Shift+End, followed by
Command+(."
4 > c add: (self foo: (knorz bar: max))|  "NICE!"

Once they learn that, I think occurrences of the line 4 case will
diminish and they'll continue to gain appreciation for Auto Enclose
(et al).

When I ran for the board I said I wanted to promote Squeak for
*power-users* over developers.   This is why I defend this position.
Text-editors are for developers who are already skilled enough to make
Squeak their own.  Squeak has really great expression-editing
capabilities which greatly help non-developer "users".  We should be
making those features even better, not surrendering and regressing
Squeak back to the way it was pre 3.7...