>> Just keep typing ) until you get there and it'll start adding.
>
> Please tell me you're kidding.

Of course I'm not.

>> Bert, the way this went down was:  1) you complained with only
>> emotion, 2) I asked for concrete clarification, 3) you clarified, 4) I
>> went and (tried to) fix to your specification, 5) you complain about a
>> new (non)problem.
>
> 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.

>> I'm trying to help here, but what is not helpful is to block any and
>> all progress with these complaints about how these non-real-world
>> use-cases aren't solved, and then to top it off, offering no guidance
>> about what it SHOULD do.
>
> Marcel and I tried to tell you exactly what it should do. And I pointed you repeatedly to an example of the right behavior. Which you continue to ignore.

Not at all.  Marcel and I were already conversing privately about
those things you said "+1 to all these" and I agree with all of them
too (except the last one for good reason which I cut-and-pasted for
you below from my conversation with Marcel).

Marcel and I tried to tell you that we don't need a stack to keep
track of that.  I actually meant, "we don't need to keep track of that
at all (stack or however)" and I think maybe Marcel meant the same but
he can clarify for himself.

> Nonsense. It's about not breaking fundamental invariants of typing behavior in the editor.

Auto Enclose is -->all about--> "breaking fundamental invariants of
typing behavior" for the benefit of assembling and editing valid,
well-formed Smalltalk expressions!

What you've done is chosen a very specific corner-case (it doesn't
even deserve to be called it a "case", so far its just a
"hypothetical") that 1) rarely occurs and 2) has an easy work-around
when it does occur, as reason to block the whole thing.

> The point is that it needs to be able to distinguish between automatically inserted parts and user-typed parts *somehow*.

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.

>>  If you have time for that go for it.  I
>> won't do it because when I analyze the use-cases, it's clear that
>> implementation is way overkill.  Not worth the effort nor the extra
>> complexity.
>
> Then the only solution right now is to turn off the feature by default. Which is what I was suggesting back at the beginning of this discussion. It's a reasonable fix until someone does it right.

I think its unfortunate and very confusing that the guy who has helped
thousands of people write well-formed and properly nested expressions
via Etoys would prefer to let one specific (hypothetical?) corner case
which occurs in < 1% of all Smalltalk code deprive new users the
benefit of helping them assemble valid, well-formed Smalltalk
expressions the other 99% of the time.

 - Chris

[1] -- In offline discussion with Marcel concerning those "+1 to all
those" items:  (Marcels is demarked by >).

Marcel wrote:

> Hmm... If there is a non-letter, non-digit, or nothing after the cursor,
> insert the closing char, too.

You mean, "only if" there is a non-letter, non-digit, right?  I think
it needs to stay as unconditional insertion.  The reason is, when I
enter or edit a method, I enjoy the luxury of not worrying at all
about formatting.  I position my cursor anywhere between two
expressions and start streaming code out of my fingers as fast as they
can type without wasting time using Return or Tab keys whatsoever.
Sure, I have ugly, unformatted code for a moment, but thanks to Auto
Enclose, I know I have whole expressions and so am assured that the
parser-formatter *can* format with a single keystroke
(Command+Shift+S).

When I initially position the cursor to insert my expression, I'm
totally unconcerned about the "text" and only looking at my code in
terms of its chunky "expressions".  So, I don't have to worry whether
the auto-enclose is going to work or not; I *know* it is going to
work.  The above proposal takes me out of my ability to do that, and
forces me to stop to think about what text / whitespace exists in
front of the cursor when I go to insert my expression.

Whew!  Sorry for the long-winded explanation..  :)  Does it make sense?

> If you remove an opening char, remove the closing one, too, if
> it follows directly.

I like that, because its consistent with the way the expression was
brought into the code; as a single gesture.

> Such chars could be () [] {} "" ''

Already there for () [] and {}.  " seems to make sense, however ' is
used so much in contractions; I don't know...