Re: Is there a preference setting to block automatic parentheses?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Is there a preference setting to block automatic parentheses?

Bert Freudenberg
(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.

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
Reply | Threaded
Open this post in threaded view
|

Re: Is there a preference setting to block automatic parentheses?

Eliot Miranda-2
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 -
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Is there a preference setting to block automatic parentheses?

Tobias Pape

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 ›‹)
Reply | Threaded
Open this post in threaded view
|

Re: Is there a preference setting to block automatic parentheses?

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





--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      
[hidden email]
Morgedalsvn. 5A       
http://folk.uio.no/trygver/
N-0378 Oslo             
http://fullOO.info
Norway                     Tel: (+47) 22 49 57 27



Reply | Threaded
Open this post in threaded view
|

Re: Is there a preference setting to block automatic parentheses?

marcel.taeumel (old)
Go to the preferences browser and disable "auto enclose".

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: Is there a preference setting to block automatic parentheses?

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: Is there a preference setting to block automatic parentheses?

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

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





Reply | Threaded
Open this post in threaded view
|

Re: Is there a preference setting to block automatic parentheses?

Chris Muller-3
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
Reply | Threaded
Open this post in threaded view
|

Re: Is there a preference setting to block automatic parentheses?

Chris Muller-3
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.

cbc
Reply | Threaded
Open this post in threaded view
|

Re: Is there a preference setting to block automatic parentheses?

cbc
In reply to this post by Tobias Pape


On Tue, Feb 24, 2015 at 2:21 AM, Tobias Pape <[hidden email]> wrote:
... 

I am constantly annoyed by code that looks like

  ()self foo: bar

(because I more often edit than write forward)
...
Best
        -Tobias

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


Reply | Threaded
Open this post in threaded view
|

Re: Is there a preference setting to block automatic parentheses?

Bert Freudenberg
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
Reply | Threaded
Open this post in threaded view
|

Re: Is there a preference setting to block automatic parentheses?

Eliot Miranda-2
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>
>

Reply | Threaded
Open this post in threaded view
|

Re: Is there a preference setting to block automatic parentheses?

marcel.taeumel (old)
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
Reply | Threaded
Open this post in threaded view
|

Re: Is there a preference setting to block automatic parentheses?

Chris Muller-3
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?

Reply | Threaded
Open this post in threaded view
|

Re: Is there a preference setting to block automatic parentheses?

marcel.taeumel (old)
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
Reply | Threaded
Open this post in threaded view
|

Re: Is there a preference setting to block automatic parentheses?

Chris Muller-3
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..

Reply | Threaded
Open this post in threaded view
|

Re: Is there a preference setting to block automatic parentheses?

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



Reply | Threaded
Open this post in threaded view
|

Re: Is there a preference setting to block automatic parentheses?

Bert Freudenberg
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
Reply | Threaded
Open this post in threaded view
|

Re: Is there a preference setting to block automatic parentheses?

marcel.taeumel (old)
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
Reply | Threaded
Open this post in threaded view
|

Re: Is there a preference setting to block automatic parentheses?

Bert Freudenberg
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
12