>> It's not about saving keystrokes.  It's about automatic closure of
>> multiple nested expressions.  Query's like this are almost impossible
>> to "type" without Auto Enclose:
>>
>
> Usually, when this happens, this is a good sign that your code needs
> refactoring.

Yes, that's why I gave the example of an ad-hoc query, because in
practice they're short "throw-away" workspace expressions rather than
factored methods.

>>
>>      ^ (cube
>>           plot: [ : dim | dim date month ]
>>           measures:
>>                [ : meas |
>>                (meas mean score plotNumber: 1)
>>                , ((meas
>>                     define: #fractionOfWinners
>>                     as: [ : cell | cell total winnerCount / cell total
>> count ]) plotNumber: 2)
>>                , (meas mean gainFactor
>>                     plotNumber: 3;
>>                     colorizer: [ : val | val > 0 ifTrue: [Color green
>> twiceDarker] ifFalse: [ Color red twiceDarker ] ]) ]
>>           where:
>>                [ : cell |
>>                (cell dimension date year equalTo: Date today asYear)
>>                | (cell dimension date year equalTo: Date today asYear
>> previous) ]) open
>>
>> It'd be much more easily "assembled", expression by expression, but
>> Auto Enclose gives typing it at least a chance of success.  :)
>>
>> >> Similarly, deleting an unwanted character is cheap, but deciding
>> >> whether
>> >> to do so is a huge cost.
>> >> I have to stop thinking about what I'm doing, and think ahead to what
>> >> I'm
>> >> going to do next. Even
>> >> if I know I'm going to need the closing character, it stays in my field
>> >> of
>> >> view and takes up cycles
>> >> as a pending thing that I have to worry about until I complete the
>> >> encoded
>> >> expression.
>>
>> So I'm surprised you don't better appreciate the atomicity of
>> expression-editing.  Deleting a paren/brace/quote character breaks the
>> code and even breaks the formatter so you can get really stuck on
>> complex expressions.  Taking an approach of expression-editing, one is
>> determined not to let the code ever be broken even for a short period
>> of time.
>>
>> >> So, the benefit is small and unreliable, while the cost is large and
>> >> inevitable. It forces me to think
>> >> about typing, which normally I don't have to do. Thus, it's
>> >> infuriating.
>>
>> Yep, I totally get you.  But if you ever decide to try committing to
>> Squeak's very capable expression-editing functions, I hope it'll work
>> out as well for you as for me.
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>
>
>