On Wed, Feb 25, 2015 at 2:23 AM, Marcel Taeumel
<marcel.taeumel at student.hpi.uni-potsdam.de> wrote:
> Hi Chris,
>
> this version is better than the original one. However, we still need:
>
> - direct removal of opening bracket should remove (automatically inserted)
> closing bracket, too

Squeak already supports that.  Simply select the expression, and then
press Command+( to remove parenthesis, Command+[ to remove [, etc.

That is one of Squeak's *expression-editing* functions.  Currently,
Squeak brilliantly supports both *text-editing* and expression-editing
simultaneously in a _modalless_ way.  The proposal to automatically
remove the inserted closing bracket by a *text-editing* operation
intrudes across the boundary between text vs. expression editing.  We
should not do that, we should maintain the current brilliant balance
between the two which we have now.

> - closing the innermost of several opening brackets should not jump to the
> end (i.e. "((((|))))" -> "(((())))|")

Okay, I fixed that by removing my special feature of skipping past the
"logical expression" (through any potential whitespace) so that now it
just checks the next character and .

> - single and double quotes should be considered, too

I'm not making enhancements right now, just trying to make this great
feature less annoying to my Squeakers.  Just spreading some love.  :)

Double-quote would require a little more work to make work wiht the
Paren-blinking function.  And single-quote is used singly often enough
(e.g., in contractions) that I'm not sure it wouldn't turn into an
annoyance -- although I can see itwould be great for typing Strings
literals..

> - opening a bracket in front of a letter should not insert the closing one,
> too (i.e. "(|Morph new")

I'm not sure I understand, but it sounds like this would again
intermix text and expression-editing in a way that would be too
intrusive for pure text-editing.  The "Auto Enclose" preference needs
to maximize its helpfulness, while minimizing its instrusiveness..