[squeak-dev] Re: Is there a preference setting to block automatic parentheses?

Tobias Pape Das.Linux at gmx.de
Thu Feb 26 00:23:57 UTC 2015


Hey,

On 26.02.2015, at 00:52, Chris Muller <asqueaker at gmail.com> wrote:

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

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

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.

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

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

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




More information about the Squeak-dev mailing list