(moving to squeak-dev)
> On 22.02.2015, at 14:40, Chris Muller <[hidden email]> 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 > 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. 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 - smime.p7s (5K) Download Attachment |
On Feb 23, 2015, at 7:25 PM, Bert Freudenberg <[hidden email]> wrote:
> (moving to squeak-dev) > >> On 22.02.2015, at 14:40, Chris Muller <[hidden email]> 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 24.02.2015, at 10:32, Eliot Miranda <[hidden email]> wrote: > On Feb 23, 2015, at 7:25 PM, Bert Freudenberg <[hidden email]> wrote: > >> (moving to squeak-dev) >> >>> On 22.02.2015, at 14:40, Chris Muller <[hidden email]> 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 ›‹) |
In reply to this post by Eliot Miranda-2
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 [hidden email] wrote:(moving to squeak-dev)On 22.02.2015, at 14:40, Chris Muller [hidden email] 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 InboxThe 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 - --
The essence of object orientation is
that objects collaborate to achieve a
goal. |
Go to the preferences browser and disable "auto enclose".
Best, Marcel |
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 |
Thanks. I looked for it but didn't find it.
On 24.02.2015 13:33, David T. Lewis
wrote:
On Tue, Feb 24, 2015 at 04:15:12AM -0800, Marcel Taeumel wrote:Go to the preferences browser and disable "auto enclose". |
In reply to this post by Eliot Miranda-2
>> 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! :) > 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 (1K) Download Attachment |
In reply to this post by Trygve
On Tue, Feb 24, 2015 at 6:48 AM, Trygve Reenskaug <[hidden email]> 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. |
In reply to this post by Tobias Pape
On Tue, Feb 24, 2015 at 2:21 AM, Tobias Pape <[hidden email]> wrote: ...
... Best Yes, this annoys me, too (which is why I turn it off). Maybe if it automatically adds the close only if it is at the end of the line (or the next space is a white space), that would work better. This added to Chris' suggestion of checking if the next character is the same closing character that you just typed and skipping over it would probably convince me to leave it on. Reasonable auto-complete + control-enclose for editing - I'd like that. -cbc |
In reply to this post by Chris Muller-3
On 24.02.2015, at 09:23, Chris Muller <[hidden email]> 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 - smime.p7s (5K) Download Attachment |
In reply to this post by Chris Muller-3
Hi Chris,
On Feb 24, 2015, at 9:23 AM, Chris Muller <[hidden email]> 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> > |
I like the way OCompletion does it. Almost. We need this behavior with one addition: You should be able to manually set braces/brackets/paren... (german: "Klammern" ^__^) around a term w/o automatic insertion of the second one if there is so selection:
|aMorph color: Color blue (|aMorph color: Color blue (aMorph color: Color blue| (aMorph color: Color blue)| Right now, this is not possible with OCompletion's Smart Characters. But the algorithm should be simple. I argue that you do not need to keep track of automatically inserted braces but only consider the text cursor and its surroundings (e.g. whitespaces or other braces). That's the way OCompletion does it. Maybe do some automatic parsing of the text to check whether there will be a closing bracket too much. ;-) Best, Marcel |
In reply to this post by Bert Freudenberg
On Tue, Feb 24, 2015 at 12:12 PM, Bert Freudenberg <[hidden email]> wrote:
> On 24.02.2015, at 09:23, Chris Muller <[hidden email]> 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? Of course not. You talked about the requirement that "typed-input should equal expected output" to address the use-case of "blind-typing". That makes perfect sense and this fix addresses that whilst preserving all of the current behaviors. The only time it could possibly be an "issue" is if you needed to pass a closer Character to the argument of a keyword message, like: (myObject includesCharacter: $)) > I think the editor needs to keep a stack of auto-inserted characters. ... which your stack wouldn't solve, but you could simply type _another_ closing paren and you're golden. That's a rare case that doesn't really behave all that badly and if there is even a worse case than that (which, I can't fathom), you have the clipboard pasting available to paste whatever you want. I made a proper version in the Inbox. Why not just try it and see if its an improvement over what we already have? |
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 |
On Wed, Feb 25, 2015 at 2:23 AM, Marcel Taeumel
<[hidden email]> 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.. |
In reply to this post by marcel.taeumel (old)
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; [hidden email]; http://www.rowledge.org/tim Useful random insult:- His head whistles in a cross wind. |
In reply to this post by marcel.taeumel (old)
On 25.02.2015, at 00:23, Marcel Taeumel <[hidden email]> 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 Yep. Typing "("-"<backspace>" needs to delete both the typed and auto-inserted parens. Similarly, typing "["-"("-"<backspace>"-"<backspace>" needs to delete the two typed and the two inserted chars. > - 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") +1 to all of these. > 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. To get it Right™, we do need a stack, IMHO. 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™ :) - Bert - smime.p7s (5K) Download Attachment |
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 |
On 25.02.2015, at 11:12, Marcel Taeumel <[hidden email]> wrote:
> > 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. No. The user doesn't have to keep track, because the editor does. It's the editor doing magic tricks, so it's the editor's responsibility to keep track of what it did. Try ACE (http://ace.c9.io), or any editor that gets it Right™. > @Bert: If you want to type another ) at "bar|))))" then you would miss an > opening brace. Huh? I of course would have inserted that opening paren before. Click somewhere in the expression, type "(", click somewhere else, type ")". Why wouldn't it let me do that? - Bert - smime.p7s (5K) Download Attachment |
Free forum by Nabble | Edit this page |