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