On 24.02.2015, at 10:32, Eliot Miranda eliot.miranda@gmail.com wrote:

On Feb 23, 2015, at 7:25 PM, Bert Freudenberg bert@freudenbergs.de wrote:

...

(moving to squeak-dev)

...

On 22.02.2015, at 14:40, Chris Muller asqueaker@gmail.com wrote:

...

...

This implmenentation is not the best. The one in E/OCompletion is better.

I love the feature (in other editors), but hate its current behavior. If that one is better, why don't we use that?

This preference is part of the low-level interface which affects the overall fidelity of the Squeak user-experience. If we are going to make any changes to this, may we please start it out in the Inbox

The onus is actually on whoever enabled this feature by default before it was mature, IMNSHO. Until we fix it properly (see below) we need to turn it off.

...

where we can all try it and discuss it in more objective terms than "love", "hate", "better" and "horrible"?

"Horrible" is a technically accurate description in this case ;)

Because it interferes with the user's wishes. It gets in the way unless you consciously anticipate how it's going to mess with what you type. And it doesn't have to, as other editors clearly demonstrate.

If I am blindly typing (foo) I expect to end up with (foo)

In current Squeak I end up with (foo)) which is clearly wrong and extremely annoying and makes me hate the feature.

For an editor that gets it right, try ACE online ( http://ace.c9.io/ ). If an editor does auto-insertion, it *must* keep track of that and anticipate the user typing the corresponding characters. E.g. in ACE I can type [('foo and get [('foo')] but then I can proceed to type ')] end it will just skip over the auto-inserted part. Similarly in Squeak when typing [(2)+(3)] it results in [(2)+(3)]))] but in ACE it gets me [(2)+(3)] which is so obviously right I'm not even sure how anyone could argue Squeak's is not horribly broken.

+1. Hate is not too strong a word. Horribly broken is accurate.

+1

I am constantly annoyed by code that looks like

()self foo: bar

(because I more often edit than write forward)

Given that Smalltalk has had control-enclose for decades that is useful and predictable we don't need something poorly engineered.

However, this is less approachable. I figured that out when I was already using Squeak for 5 years. I for one would like "delimiter character"[1] to just behave like auto-enclose if (and only if) there is a text selection

Can we either get it right or get rid of it, please?

Best -Tobias

[1]: my list of these (to not forget them) [], {}, (), <> (and >< too), "", '', `` more esotheric || (helpful for temps) _ _, * *, = =, # #, + + (helpful for emphasis in comments) and probably (a little harder) “”, ‘’, „“, «» (or »«), ‹› (or ›‹)

This is all about the future. But how do I get rid of the automatic $) NOW? I'm not quarreling with other people's preferences, only that I personally need the option to work without it.

On 24.02.2015 10:32, Eliot Miranda wrote:

On Feb 23, 2015, at 7:25 PM, Bert Freudenberg bert@freudenbergs.de wrote:

...

(moving to squeak-dev)

...

On 22.02.2015, at 14:40, Chris Muller asqueaker@gmail.com wrote:

...

...

...

Some people like this preference a lot. Others think it is horrible.

This implmenentation is not the best. The one in E/OCompletion is better.

I love the feature (in other editors), but hate its current behavior. If that one is better, why don't we use that?

This preference is part of the low-level interface which affects the overall fidelity of the Squeak user-experience. If we are going to make any changes to this, may we please start it out in the Inbox

The onus is actually on whoever enabled this feature by default before it was mature, IMNSHO. Until we fix it properly (see below) we need to turn it off.

...

where we can all try it and discuss it in more objective terms than "love", "hate", "better" and "horrible"?

"Horrible" is a technically accurate description in this case ;)

Because it interferes with the user's wishes. It gets in the way unless you consciously anticipate how it's going to mess with what you type. And it doesn't have to, as other editors clearly demonstrate.

If I am blindly typing (foo) I expect to end up with (foo)

In current Squeak I end up with (foo)) which is clearly wrong and extremely annoying and makes me hate the feature.

For an editor that gets it right, try ACE online ( http://ace.c9.io/ ). If an editor does auto-insertion, it *must* keep track of that and anticipate the user typing the corresponding characters. E.g. in ACE I can type [('foo and get [('foo')] but then I can proceed to type ')] end it will just skip over the auto-inserted part. Similarly in Squeak when typing [(2)+(3)] it results in [(2)+(3)]))] but in ACE it gets me [(2)+(3)] which is so obviously right I'm not even sure how anyone could argue Squeak's is not horribly broken.

+1. Hate is not too strong a word. Horribly broken is accurate. Given that Smalltalk has had control-enclose for decades that is useful and predictable we don't need something poorly engineered. Can we either get it right or get rid of it, please?

...

So, as others have pointed out, it's not that we don't want the editor to be helpful, it is a very useful feature, but it must be mindful of what the user wants.

• Bert -

On Tue, Feb 24, 2015 at 04:15:12AM -0800, Marcel Taeumel wrote:

Go to the preferences browser and disable "auto enclose".

It is located in preference category "Morphic", so under "Tools" on the toolbar, open a Preference Browser. Select category "Morphic", and then disable the "auto enclose" preference.

Dave

On Tue, Feb 24, 2015 at 6:48 AM, Trygve Reenskaug trygver@ifi.uio.no wrote:

Thanks. I looked for it but didn't find it.

If you type "paren"(thesis) or "brack"(et) into the Preferences search, it's the only search result.

On 24.02.2015, at 09:23, Chris Muller asqueaker@gmail.com wrote:

Try filing in the attached patch and see if it does what you want.

MNU: nextNonwhitespaceCharacter

It simply checks the next non-whitespace character in front of the cursor and if its the same closer that was typed, simply advances the cursor rather than type the closing character.

This sounds too simplistic to me. Wouldn't that mean I can never insert an additional closing paren?

I think the editor needs to keep a stack of auto-inserted characters.

- Bert -

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 - closing the innermost of several opening brackets should not jump to the end (i.e. "((((|))))" -> "(((())))|") - single and double quotes should be considered, too - opening a bracket in front of a letter should not insert the closing one, too (i.e. "(|Morph new")

I agree with you that we do not need a stack of automatically inserted brackets but only consider the current context of the text cursor.

Best, Marcel

-- View this message in context: http://forum.world.st/Re-Is-there-a-preference-setting-to-block-automatic-pa... Sent from the Squeak - Dev mailing list archive at Nabble.com.

Shouldn’t the automatic text completion & wrapping stuff be made a part of Shout? Seems like a place where textual/semantic analysis is being done already, where one might be able to work out whether a ( is closing a chunk that already has a ) etc.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- His head whistles in a cross wind.

Hmm... I guess the user keeps track on what she sees on the screen. Such a stack of inserted backets must be discoverable/visible somehow. That's why I think simple context recognition (i.e. the character next du the text cursor) should be enough and quite discoverable/usable.

We could do it like this: If there is a non-letter-non-digit or nothing after the cursor, insert the closing char, too. If you type that closing char yourself, overwrite it--one after another. If you remove an opening char, remove the closing one, too, if it follows directly. Typing the opening char on a selection of text encloses that selection.

Such chars could be () [] {} "" ''

Eclipse seems to do it roughly this way...except for the selection trick. But I like that. :)

@Bert: If you want to type another ) at "bar|))))" then you would miss an opening brace. ;) If not, you would have to append it after the last ) -- like it is in OCompletion right now.

Best, Marcel

-- View this message in context: http://forum.world.st/Re-Is-there-a-preference-setting-to-block-automatic-pa... Sent from the Squeak - Dev mailing list archive at Nabble.com.

Morphic-cmm.760 still ignores what the user typed. It *explicitly* ignores it. If I have "bar)))))" and want to type another ")" after the "r", it does not let me. And that's not Right™ :)

Anytime you have multiple consecutive closers of the same type, it doesn't matter whether you add it to the front or the end. Just keep typing ) until you get there and it'll start adding.

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.

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.

It's clear this is more about you wanting to complicate the implementation with a stack. 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.

Just be sure to please start it out in the Inbox first so I can offer my own critique..

...

...

Morphic-cmm.760 still ignores what the user typed. It *explicitly* ignores it. If I have "bar)))))" and want to type another ")" after the "r", it does not let me. And that's not Right™ :)

Anytime you have multiple consecutive closers of the same type, it doesn't matter whether you add it to the front or the end. Just keep typing ) until you get there and it'll start adding.

Oh yes it does matter. If I click to position the cursor and type some character, then yes i expect some character to be inserted where I clicked.

Which is exactly what it does except for the case where you would desire to mess up the balance of your nested expressions..

If I want to do something special, then I prefer to tell it with some special key combination (alt ctrl cmd esc whatever...).

I think what you said you want to do in your above paragraph sounds like "something special". With Auto Enclose already on, there should be no need to ever insert your own closers, which means you're just talking about *extra* closers (or closer characters that are not being used as closers), and *even then* would only trip your gripe if the very next character happened to be the same closer-character.

Is it really worth putting so much effort and complexity to cover the case that occurs that rarely?

... snip...

The real world use case is to let the most simple behaviour just work.

Could you possibly articulate a real-world use-case DOESN'T "just work?"

I think Bert gave example of behaviour in a form of a link. Maybe that is not detailed enough, but it's a guidance already.

Give one example of Smalltalk code that works in Ace but not TextEditor that a Smalltalker would care about.

A program that does not fullfil my expectations just for the sake of being simple to implement is not of high value. What matters more than implementation is a versatile and unsurprising behavior of the editor.

It's when its simple that users can get to understand its behavior so that it is not surprising. It's when we make it so overly complicated with so many rules and internal stacks or speical-characters that the surprises creep in..

Such complex solutions to such rare corner cases is the kind of thing I think that the Pharo camp might refer to as "crap"...

That's why a majority of us simply prefer no auto-completion at all rather than a broken one.

(I assume by "auto-completion" you mean Auto Enclose). There is no data that a "majority" prefers it off, certainly not with the new enhacnement in the Inbox, because it has not had enough usage for people to try it and weigh in.

I'd prefer to be more positive and helpful, but Chris, you have to understand our griefs: we don't want compromise or workaround, We want an editor that just works.

I am making effort to understand your grief. That's why I prodded y'all for details and worked up an Inbox contributions.

You are making progress and yet improving the gadget, but the minimum features to make it acceptable is not yet there. Please keep on :)

For me, Auto Enclose was already good enough even before Morphic-cmm.759. For just a little code change, Morphic-cmm.760, while surely not perfect, was my attempt to provide a decent step of improvement TOWARD what you guys expressed your dissatisfaction about.

Regards, Chris

...

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

One more argument against the stack:

(

... |aMorph ...

)

The last parenthesis was inserted automatically. No the user types another one:

(

... (|aMorph ...

)

Finally, she wants to close that at the end. Now, where to place the cursor? She forgot. The behavior is unexpected. If she tries this:

(

... (aMorph ...

|)

The closing one will be overwritten, because it was inserted automatically. The stack keeps track of it.

(

... (aMorph ...

)|

Here, it is clear that a new closing parenthesis will be appended. Now if you have this:

(((((

...

))|)))

You have *no clue* what will happen if there is a magic stack that manages those auto-parenthesis.

I still vote for a simple, clear, local semantic here.

Best, Marcel

-- View this message in context: http://forum.world.st/Re-Is-there-a-preference-setting-to-block-automatic-pa... Sent from the Squeak - Dev mailing list archive at Nabble.com.

On 26.02.2015, at 04:05, Marcel Taeumel marcel.taeumel@student.hpi.uni-potsdam.de wrote:

Okay. Tim just explained to me, what Bert's "stack" actually means, and that it is not necessarily a stack from an implementation point of view but merely a smart counter. :)

Sounds reasonable. And much cheaper than asking the Parser if there are too few closing brackets. And similar (even better) from a usability perspective.

What I was proposing (and what is *standard* behavior in about any code editor) has nothing to do with the parser. It is not counting any parens that are in the text already. It's not even aware of syntax. It merely temporarily keeps track of what was auto-inserted, on a single line, not globally, not forever. As soon as you move the cursor you're back to regular, non-magic editing.

Auto-inserted parens are magic. This magic lasts until the user is done editing that single expression. It should be nothing fancy from a user's point of view. Using it should not be any more complicated than using a non-magic editor. But most importantly, the magic must not get in the way. We should delight our users with magic, not make them wish for a dumb editor because the magic is annoying.

I will look into it later this day.

Awesome!

- Bert -

...

...

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 know what you're talking about, which is why I'm surprised anyone would want to try to make it even smarter than it already is. Right now, the user can simply look at what text is at the cursor and, from that, ascertain the behavior that pressing the next key will evoke.

With what is being proposed by Bert, the user will now have to examine the full nesting, count the parentheses and brackets, maybe check the leading character, etc. to understand why it did, or did not, insert their closer character. The whole purpose of Auto Enclose (et al) is to relieve the user from ever having to go through this tedious exercise.

And what about when their expressions will get out-of-balance? Will the system handle that "perfectly" and how will the user understand what happened when they typed a character and the system didn't behave like they thought because it was so complicated.

I think we're in agreement about what we want the user experience to be, I just think we totally disagree about how it should be provided.

...

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 )

1 > self foo: (knorz bar: max) "ah, there is something missing" 2 > |self foo: (knorz bar: max) " ... " 3 > c add: |self foo: (knorz bar: max) " oh, that now needs parens " 4 > c add: ()|self foo: (knorz bar: max) " ARGH " 5 > c add: (|self foo: (knorz bar: max) " Backspace " 6 > c add: (self foo: (knorz bar: max|) " maybe an off by one? add +1 " 7 > c add: (self foo: (knorz bar: max + 1|) " Ohm a closing paren still missing. I now type )" 8 > c add: (self foo: (knorz bar: max + 1)| " ARGH "

This is a good working example, thanks, let's look at this together (I added line numbers for reference).

At line 4, the cursor is actually between the parens, like this:

c add: (|)self foo: (knorz bar: max)

I understand your ARGH at line 4, but there's a problem with the one at line 8. Because this user is starting to work on their /next/ expression (max+1) before they finished their /current/ expression (c add: (self foo: (knorz bar: max))). Maybe you have a "dual-core" brain where mine is only a single-core, because I think a normal user would not do that. I think users who are trying to work on multiple expressions at once are the ones who will most benefit from Auto Enclose. IOW, just for clarity, here is the process a normal user would follow:

0 > self foo: (|) "ah, the system typed the closing paren for me, NICE!" 1 > self foo: (knorz bar: max) "ah, there is something missing" 2 > |self foo: (knorz bar: max) " ... " 3 > c add: |self foo: (knorz bar: max) " oh, that now needs parens " 4 > c add: (|)self foo: (knorz bar: max) "ah, the system saved me a keystroke at 0, so I understand why it did this, is there a better way?" 5 > c add: (|self foo: (knorz bar: max) "Delete" 5.1 > c add: (self foo: (knorz bar: max)| "End key" 5.2 > c add: (self foo: (knorz bar: max))| "Closing paren. Expression modification completed. Next?" 6 > c add: (self foo: (knorz bar: max|)) "maybe an off by one? add +1 " 7 > c add: (self foo: (knorz bar: max + 1|)) "Ohm a closing paren still missing. I now type )" 8 > c add: (self foo: (knorz bar: max + 1)|) "System did not insert an additional paren, NICE!"

So, that leaves your ARGH at line 4 but because of what happened at 0, the user probably understands what and why it happened. So instead of saying "ARGH" I think they might be more inquisitive to ask, "Is there a better way?" Which, of course, there is:

3 > c add: |self foo: (knorz bar: max) "Press Shift+End, followed by Command+(." 4 > c add: (self foo: (knorz bar: max))| "NICE!"

Once they learn that, I think occurrences of the line 4 case will diminish and they'll continue to gain appreciation for Auto Enclose (et al).

When I ran for the board I said I wanted to promote Squeak for *power-users* over developers. This is why I defend this position. Text-editors are for developers who are already skilled enough to make Squeak their own. Squeak has really great expression-editing capabilities which greatly help non-developer "users". We should be making those features even better, not surrendering and regressing Squeak back to the way it was pre 3.7...

...

I think users who are trying to work on multiple expressions at once are the ones who will most benefit from Auto Enclose. IOW, just for clarity, here is the process a normal user would follow:

0 > self foo: (|) "ah, the system typed the closing paren for me, NICE!" 1 > self foo: (knorz bar: max) "ah, there is something missing" 2 > |self foo: (knorz bar: max) " ... " 3 > c add: |self foo: (knorz bar: max) " oh, that now needs parens " 4 > c add: (|)self foo: (knorz bar: max) "ah, the system saved me a keystroke at 0, so I understand why it did this, is there a better way?" 5 > c add: (|self foo: (knorz bar: max) "Delete" 5.1 > c add: (self foo: (knorz bar: max)| "End key"

Does not work If there is stuff after that, (which it typically is). Also, All keyboards I use have no dedicated 'end' key and, Ctrl-e (as in every unix) does not work.

Then use the arrows or click there. We're talking about Auto Enclose not navigation..

...

5.2 > c add: (self foo: (knorz bar: max))| "Closing paren. Expression modification completed. Next?"

I do not at all think in 'expression modification'. This does not work in comments, either.

...

6 > c add: (self foo: (knorz bar: max|)) "maybe an off by one? add +1 " 7 > c add: (self foo: (knorz bar: max + 1|)) "Ohm a closing paren still missing. I now type )" 8 > c add: (self foo: (knorz bar: max + 1)|) "System did not insert an additional paren, NICE!"

...

So, that leaves your ARGH at line 4 but because of what happened at 0, the user probably understands what and why it happened. So instead of saying "ARGH" I think they might be more inquisitive to ask, "Is there a better way?" Which, of course, there is:

3 > c add: |self foo: (knorz bar: max) "Press Shift+End, followed by Command+(."

again, no end key.

This is off topic.. simply use another means to select the expression, there are several ways.

and how should I type Command+(? like, Command-Shift-9? Ok.

Yes.

Why not '(' at that point.

Because that is used to /replace/ the currently selected expression with a new expression. Selection replace is how all editors work, and we agreed we wish to minimize surprises and violations of typing behavior invariants.

...

4 > c add: (self foo: (knorz bar: max))| "NICE!"

Once they learn that, I think occurrences of the line 4 case will diminish and they'll continue to gain appreciation for Auto Enclose (et al).

Chris, I work for +5 year with Editors where I cannot disable auto-enclose and I constantly get this

| "type (" (|) "i just wanted (, Delete" | "Whut? (" (|) "again? Backspace" | "Whut? (" (|) "Ok. 'right'" ()| "Backspace " (| "finally"

Actually, the "delete" case is rare, as I have to type fn+BACKSPACE.

The above may be the case for other editors, but not Squeak. With Squeak, the worst you have is:

| "type (" (|) "i just wanted (, Delete" (| "finally"

When one considers all the cases where Auto Enclose helps by keeping one's expression nestings balanced, I think the problem of 2nd line above becomes understandable to the user, and, if it is happening "constantly" that they will like to learn and use the better way; of selecting the expression and pressing Command+(..

You are an experienced developer who has his ways set by now; I'm more interested for this feature to help new users who want to be empowered by a system suitable for power-users and not just developers..

Hi Chris,

On Feb 24, 2015, at 9:23 AM, Chris Muller asqueaker@gmail.com wrote:

...

...

If I am blindly typing (foo) I expect to end up with (foo)

In current Squeak I end up with (foo)) which is clearly wrong and extremely annoying and makes me hate the feature.

Okay, thanks for explaining that. Sure, that's how eclipse works too. I figured that's what you meant, but I wasn't sure because wailing about that is almost harder than simply fixing it. ;)

Try filing in the attached patch and see if it does what you want. It simply checks the next non-whitespace character in front of the cursor and if its the same closer that was typed, simply advances the cursor rather than type the closing character.

...

...

... snip ... which is so obviously right I'm not even sure how anyone could argue Squeak's is not horribly broken.

Eliot wrote:

...

+1. Hate is not too strong a word. Horribly broken is accurate.

Guys, I thought *I* was the emotional one. If you reserve such strong words for things this small then you won't be able to differentiate from the bigger things. I've been learning that such words are not always the most productive way to criticize and can can make others feel bad.. Lighten up people! :)

:). Maybe you're taking the reaction to the feature personally. I don't hate you but yes, I /do/ hate the auto enclose because do often it does the wrong thing, causes me to to have to compensate with editing and therefore breaks my flow. It is /so/ in my face. I do hate it.

...

Given that Smalltalk has had control-enclose for decades that is useful and predictable we don't need something poorly engineered. Can we either get it right or get rid of it, please?

There is no chance this feature will be removed because it is one of several necessary components that make up a fantastic suite of expression-editing functions. Some people operate by "editing text" and others by "editing expressions". This feature is an absolutely essential component of a group of functions for the latter; along with Control+enclose, Expression-selection (via Command+[space]), and Paren-Blinking. I've put quite a bit of thought into this..

Please check out the attached improvement, and I hope you can switch your hate to love... :)

...

...

So, as others have pointed out, it's not that we don't want the editor to be helpful, it is a very useful feature, but it must be mindful of what the user wants.

• Bert -

<TextEditor-dispatchOnKeyboardEvent.st.gz>