On 26.02.2015, at 17:11, Chris Muller asqueaker@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