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