On 26.02.2015, at 17:11, Chris Muller <asqueaker at gmail.com> wrote:

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

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

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

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'

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

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