>> > Morphic-cmm.760 still ignores what the user typed. It *explicitly*
>> > ignores it. If I have "bar)))))" and want to type another ")" after the "r",
>> > it does not let me. And that's not Right™ :)
>>
>> Anytime you have multiple consecutive closers of the same type, it
>> doesn't matter whether you add it to the front or the end.  Just keep
>> typing ) until you get there and it'll start adding.
>>
>
> Oh yes it does matter.
> If I click to position the cursor and type some character, then yes i expect
> some character to be inserted where I clicked.

Which is exactly what it does except for the case where you would
desire to mess up the balance of your nested expressions..

> If I want to do something special, then I prefer to tell it with some
> special key combination (alt ctrl cmd esc whatever...).

I think what you said you want to do in your above paragraph sounds
like "something special".  With Auto Enclose already on, there should
be no need to ever insert your own closers, which means you're just
talking about *extra* closers (or closer characters that are not being
used as closers), and *even then* would only trip your gripe if the
very next character happened to be the same closer-character.

Is it really worth putting so much effort and complexity to cover the
case that occurs that rarely?

> ... snip...
>
> The real world use case is to let the most simple behaviour just work.

Could you possibly articulate a real-world use-case DOESN'T "just work?"

> I think Bert gave example of behaviour in a form of a link. Maybe that is
> not detailed enough, but it's a guidance already.

Give one example of Smalltalk code that works in Ace but not
TextEditor that a Smalltalker would care about.

> A program that does not fullfil my expectations just for the sake of being
> simple to implement is not of high value.
> What matters more than implementation is a versatile and unsurprising
> behavior of the editor.

It's when its simple that users can get to understand its behavior so
that it is not surprising.  It's when we make it so overly complicated
with so many rules and internal stacks or speical-characters that the
surprises creep in..

Such complex solutions to such rare corner cases is the kind of thing
I think that the Pharo camp might refer to as "crap"...

> That's why a majority of us simply prefer no auto-completion at all rather
> than a broken one.

(I assume by "auto-completion" you mean Auto Enclose).  There is no
data that a "majority" prefers it off, certainly not with the new
enhacnement in the Inbox, because it has not had enough usage for
people to try it and weigh in.

> I'd prefer to be more positive and helpful, but Chris, you have to
> understand our griefs: we don't want compromise or workaround,
> We want an editor that just works.

I am making effort to understand your grief.  That's why I prodded
y'all for details and worked up an Inbox contributions.

> You are making progress and yet improving the gadget, but the minimum
> features to make it acceptable is not yet there.
> Please keep on :)

For me, Auto Enclose was already good enough even before
Morphic-cmm.759.  For just a little code change, Morphic-cmm.760,
while surely not perfect, was my attempt to provide a decent step of
improvement TOWARD what you guys expressed your dissatisfaction about.

Regards,
  Chris