Re: Is there a preference setting to block automatic parentheses?

> 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.

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.

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.

It's clear this is more about you wanting to complicate the
implementation with a stack.  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.

Just be sure to please start it out in the Inbox first so I can offer
my own critique..

On 25.02.2015, at 12:52, Chris Muller <[hidden email]> wrote:

> Just keep typing ) until you get there and it'll start adding.

Please tell me you're kidding.

> 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".

> 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.

> It's clear this is more about you wanting to complicate the
> implementation

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

> with a stack.

If you can make the editor keep track of what it auto-inserted by something else than a stack, yay, go for it. The point is that it needs to be able to distinguish between automatically inserted parts and user-typed parts *somehow*.

>  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.

- Bert -

>> 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...

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

Hey,

On 26.02.2015, at 00:52, Chris Muller <[hidden email]> wrote:

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

It is? I thought it is just for putting parens around stuff.
Because code is not all there is™.

>
> 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

nope.

See: code I have ( | is cursor )

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

Best
        -Tobias

One more argument against the stack:


(

... |aMorph ...

)


The last parenthesis was inserted automatically. No the user types another one:


(

... (|aMorph ...

)

Finally, she wants to close that at the end. Now, where to place the cursor? She forgot. The behavior is unexpected. If she tries this:

(

... (aMorph ...

|)

The closing one will be overwritten, because it was inserted automatically. The stack keeps track of it.

(

... (aMorph ...

)|

Here, it is clear that a new closing parenthesis will be appended. Now if you have this:

(((((

...

))|)))

You have *no clue* what will happen if there is a magic stack that manages those auto-parenthesis.

I still vote for a simple, clear, local semantic here.

Best,
Marcel

Okay. Tim just explained to me, what Bert's "stack" actually means, and that it is not necessarily a stack from an implementation point of view but merely a smart counter. :)

Sounds reasonable. And much cheaper than asking the Parser if there are too few closing brackets. And similar (even better) from a usability perspective.

I will look into it later this day.

Best,
Marcel

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.

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...

On 26.02.2015, at 17:11, Chris Muller <[hidden email]> wrote:

No. I type earlier than I see. To actively having to decide whether to
press 'right' or ')' disrupts my flow. Not cool.

That has nothing to do with 'dual-core' but just "scanning left-to-right",
and encountering another thing I have to do. Call it 'thought stacking'
or more commonly known as 'yak shaving'

Does not work If there is stuff after that, (which it typically is).
Also, All keyboards I use have no dedicated 'end' key and, Ctrl-e (as in every unix) does not work.

> 5.2 > c add: (self foo: (knorz bar: max))|   "Closing paren.
> Expression modification completed.  Next?"

I do not at all think in 'expression modification'.
This does not work in comments, either.

> 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+(."

again, no end key.
and how should I type Command+(? like, Command-Shift-9? Ok.
Why not  '(' at that point.

> 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).

Chris, I work for +5 year with Editors where I cannot disable auto-enclose and
I constantly get this

| "type ("
(|) "i just wanted (, Delete"
| "Whut? ("
(|) "again? Backspace"
| "Whut? ("
(|) "Ok. 'right'"
()| "Backspace "
(| "finally"

Actually, the "delete" case is rare, as I have to type fn+BACKSPACE.

>
> 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...

Then I just want the basic Readline keybindings. Really.
No Magic, just line editing. No expression editing.


Best
        -Tobias

Excerpts from Chris Muller's message of 2015-02-26 17:11:35 +0100:
> 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?"

pharo solves this problem by not inserting a closing ) if there is other text
right after the cursor:

3 >  c add: |self foo: (knorz bar: max)      " oh, that now needs parens "
4 >  c add: (|self foo: (knorz bar: max)

if i wanted to insert a new expression i'd type:

3 >  c add: |self foo: (knorz bar: max)      " oh, that now needs parens "
4 >  c add:| self foo: (knorz bar: max)      " back off to get some space"
3 >  c add: (|) self foo: (knorz bar: max)   " type space and ( ..."

in the other case it behaves the same.

what i am wondering is, why at line 1, once the user moved away from the
closing ) it does not count as accepted?

that would solve the problem in line 8, because, someone typing without paying
attention to the auto-inserts would not move the cursor without actually typing
the ) directly.

greetings, martin.

--
eKita                   -   the online platform for your entire academic life
--
chief engineer                                                       eKita.co
pike programmer      pike.lysator.liu.se    caudium.net     societyserver.org
secretary                                                      beijinglug.org
mentor                                                           fossasia.org
foresight developer  foresightlinux.org                            realss.com
unix sysadmin
Martin Bähr          working in china        http://societyserver.org/mbaehr/

Then use the arrows or click there.  We're talking about Auto Enclose
not navigation..

This is off topic..  simply use another means to select the
expression, there are several ways.

> and how should I type Command+(? like, Command-Shift-9? Ok.

Yes.

> Why not  '(' at that point.

Because that is used to /replace/ the currently selected expression
with a new expression.  Selection replace is how all editors work, and
we agreed we wish to minimize surprises and violations of typing
behavior invariants.

The above may be the case for other editors, but not Squeak.  With
Squeak, the worst you have is:

|       "type ("
(|)     "i just wanted (, Delete"
(|      "finally"

When one considers all the cases where Auto Enclose helps by keeping
one's expression nestings balanced, I think the problem of 2nd line
above becomes understandable to the user, and, if it is happening
"constantly" that they will like to learn and use the better way; of
selecting the expression and pressing Command+(..

You are an experienced developer who has his ways set by now; I'm more
interested for this feature to help new users who want to be empowered
by a system suitable for power-users and not just developers..

On 26.02.2015, at 04:05, Marcel Taeumel <[hidden email]> wrote:
>
> Okay. Tim just explained to me, what Bert's "stack" actually means, and that
> it is not necessarily a stack from an implementation point of view but
> merely a smart counter. :)
>
> Sounds reasonable. And much cheaper than asking the Parser if there are too
> few closing brackets. And similar (even better) from a usability
> perspective.

What I was proposing (and what is *standard* behavior in about any code editor) has nothing to do with the parser. It is not counting any parens that are in the text already. It's not even aware of syntax. It merely temporarily keeps track of what was auto-inserted, on a single line, not globally, not forever. As soon as you move the cursor you're back to regular, non-magic editing.

Auto-inserted parens are magic. This magic lasts until the user is done editing that single expression. It should be nothing fancy from a user's point of view. Using it should not be any more complicated than using a non-magic editor. But most importantly, the magic must not get in the way. We should delight our users with magic, not make them wish for a dumb editor because the magic is annoying.

> I will look into it later this day.

Awesome!

- Bert -

Hello,

2015-02-26 18:11 GMT+01:00 Chris Muller <[hidden email]>:
I doubt that Command+( is a widely known or sufficiently advertised
feature. In fact, before you mentioned it in this discussion I
believed only OCompletion would provide this desirable feature
(without Command) and I have used Squeak for 2.5 years. The keyboard
shortcut list does mention it (and some more which I will happily use
from now on) but the list starts out rather unhelpfully sorted if you
want to discover "power-user" features and currently also contains
some errors (or some shortcuts do not function correctly), but that is
a different problem.

Therefore, I would prefer when ( with selected text would surround
that text with brackets instead of replacing it or at least Command+(
etc. be advertised somehow.

Personally, I am also fine with skipping brackets in the |))) --> )|))
case because I am used to it from Eclipse and might want to reach a
place in between those brackets to add further arguments... but I
would, like Bert if I understood him correctly, also prefer this
behavior to stop and an additional parenthesis be inserted if the
cursor has been moved with the arrow keys, by mouse click etc. And for
the statistics, I also dislike "|foo" --> "(|)foo" (like most of us)
and generally reaching for the navigation keys to write new code.
Pharo's behavior as described by Martin seems like a good compromise
to me.

I also wonder how many people actually write or edit text with
expressions first in mind, like you do, Chris. I figure it is a good
idea for writing formulas (e. g. using a workspace as a calculator),
but at least it did not come to my mind as such for coding (in
languages where you "write in words" and parentheses are mostly
written for the machine).

Best regards,
Jakob