eCompletion tweak for smart characters

> Guys - this is my first attempt at a contribution - and I'm not sure how literally to take the advice on "how to contribute to Pharo" for a small change. Should I create an issue, and post it here (happy to do that, but wondered if conversation might be useful first as I'm new to this).
>
> Given that I'm not sure what the relationship between eCompletion and oCompletion is (someone mentioned the latter is built on top of the former?) - so maybe I'm barking up the wrong tree, however I was impressed with how much quicker Lucas' Hudson built pharo image was with eCompletion so I've been trying that for a few days (although I've noticed some mails on oCompletion but haven't gone back to retry it).
>
> Anyway - I have attached a change set that changes how smart characters work - instead of turning them off because half of the time they do the wrong thing for me and I madly press delete, I wanted to preserve the other half of the time when I'm entering new code and they give me a helpful template.
>
> My proposed fix is for the following scenario - if I go to add an extra bracket around an expression (becuase I later realise that I need to designate a keyword expression) I get two brackets - and then I backspace and they both go, so then I do it again and press delete... Instead I think there is a heuristic which says that says if you type a smart character with the cursor next to a non-whitespace item, you probably don't want the matching character. e.g.
>
> 5 max: 4 > 3 ifTrue: [] {cursor here} - and I click next to the 4 (or the 5) to put the bracket and I get 2, and I really only want one.
>
> My patch tries to address this.
>
> I also didn't see any test cases for this stuff (and possibly some could be written - should I try to do that too?).
>
> Tim

> Given that I'm not sure what the relationship between eCompletion and oCompletion is (someone mentioned the latter is built on top of the former?) - so maybe I'm barking up the wrong tree, however I was impressed with how much quicker Lucas' Hudson built pharo image was with eCompletion so I've been trying that for a few days (although I've noticed some mails on oCompletion but haven't gone back to retry it).
>
> Anyway - I have attached a change set that changes how smart characters work - instead of turning them off because half of the time they do the wrong thing for me and I madly press delete, I wanted to preserve the other half of the time when I'm entering new code and they give me a helpful template.
>
> My proposed fix is for the following scenario - if I go to add an extra bracket around an expression (becuase I later realise that I need to designate a keyword expression) I get two brackets - and then I backspace and they both go, so then I do it again and press delete... Instead I think there is a heuristic which says that says if you type a smart character with the cursor next to a non-whitespace item, you probably don't want the matching character. e.g.
>
> 5 max: 4 > 3 ifTrue: [] {cursor here} - and I click next to the 4 (or the 5) to put the bracket and I get 2, and I really only want one.
>
> My patch tries to address this.
>
> I also didn't see any test cases for this stuff (and possibly some could be written - should I try to do that too?).
>
> Tim<ECControllerTimMackinnon.1.cs>

>
> always create an issue else we forget.... too much stuff to do.
> Then conversation is always good. Because we build a shared mindset and we
> all learn together
>
> OK - done (2743) - I followed the instructions
> on http://code.google.com/p/pharo/wiki/HowToContribute - which are great (by
> the way there are a few typos in that text, and here are simple corrections
> - i think its fairly easy to spot the sections they replace):
> You can find the license that you should sign
> here: http://code.google.com/p/pharo/wiki/LicenseAgreement.
> We value your fixes and we always try to look at them and give feedback to
> you, this works best if you create a bug entry in the bug tracker. Without
> it we may have problem giving you feedback or letting you know that there is
> another fix.
> The most important point is that you check your fix in a fresh (probably
> latest) image. There are two alternatives to packaging your code: You can
> send a changeset or a set of packages. For complex changes that involves
> several packages use a slice as there is a much better merging support.
> While we prefer packages, if it is easier for you send changesets, then we
> accept those too.
> Prepare a changeset with your changes. File it out. Important: Put your Full
> name instead of your initials, as it will help up to contact you which is
> often necessary. Only alphabetical characters, and Do Not use any spaces.
>
>
> Tim
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> If you register as a developper on the Google code website, you could
> modify the wiki by yourself ;-)
>
> 2010/8/3 Tim Mackinnon <[hidden email]>:
>>
>> always create an issue else we forget.... too much stuff to do.
>> Then conversation is always good. Because we build a shared mindset  
>> and we
>> all learn together
>>
>> OK - done (2743) - I followed the instructions
>> on http://code.google.com/p/pharo/wiki/HowToContribute - which are  
>> great (by
>> the way there are a few typos in that text, and here are simple  
>> corrections
>> - i think its fairly easy to spot the sections they replace):
>> You can find the license that you should sign
>> here: http://code.google.com/p/pharo/wiki/LicenseAgreement.
>> We value your fixes and we always try to look at them and give  
>> feedback to
>> you, this works best if you create a bug entry in the bug tracker.  
>> Without
>> it we may have problem giving you feedback or letting you know that  
>> there is
>> another fix.
>> The most important point is that you check your fix in a fresh  
>> (probably
>> latest) image. There are two alternatives to packaging your code:  
>> You can
>> send a changeset or a set of packages. For complex changes that  
>> involves
>> several packages use a slice as there is a much better merging  
>> support.
>> While we prefer packages, if it is easier for you send changesets,  
>> then we
>> accept those too.
>> Prepare a changeset with your changes. File it out. Important: Put  
>> your Full
>> name instead of your initials, as it will help up to contact you  
>> which is
>> often necessary. Only alphabetical characters, and Do Not use any  
>> spaces.
>>
>>
>> Tim
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Serge Stinckwich
> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
> Every DSL ends up being Smalltalk
> http://doesnotunderstand.org/
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> I never noticed that.... (slaps his forehead - it is a wiki after all). I'll make those changes.
>
> Tim
>
> On 3 Aug 2010, at 12:18, Serge Stinckwich wrote:
>
>> If you register as a developper on the Google code website, you could
>> modify the wiki by yourself ;-)
>>
>> 2010/8/3 Tim Mackinnon <[hidden email]>:
>>>
>>> always create an issue else we forget.... too much stuff to do.
>>> Then conversation is always good. Because we build a shared mindset and we
>>> all learn together
>>>
>>> OK - done (2743) - I followed the instructions
>>> on http://code.google.com/p/pharo/wiki/HowToContribute - which are great (by
>>> the way there are a few typos in that text, and here are simple corrections
>>> - i think its fairly easy to spot the sections they replace):
>>> You can find the license that you should sign
>>> here: http://code.google.com/p/pharo/wiki/LicenseAgreement.
>>> We value your fixes and we always try to look at them and give feedback to
>>> you, this works best if you create a bug entry in the bug tracker. Without
>>> it we may have problem giving you feedback or letting you know that there is
>>> another fix.
>>> The most important point is that you check your fix in a fresh (probably
>>> latest) image. There are two alternatives to packaging your code: You can
>>> send a changeset or a set of packages. For complex changes that involves
>>> several packages use a slice as there is a much better merging support.
>>> While we prefer packages, if it is easier for you send changesets, then we
>>> accept those too.
>>> Prepare a changeset with your changes. File it out. Important: Put your Full
>>> name instead of your initials, as it will help up to contact you which is
>>> often necessary. Only alphabetical characters, and Do Not use any spaces.
>>>
>>>
>>> Tim
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Serge Stinckwich
>> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
>> Every DSL ends up being Smalltalk
>> http://doesnotunderstand.org/
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Hi Tim,
>
> Thank you for the contribution. I will definitely look at it as soon
> as I get access to a computer  again (i am a few days away right now).
>
> Testing this would be definitely cool, especially given all the edge
> cases. It is certainly testable, but kind of tricky to setup
> everything.
>
> Lukas
>
> On Tuesday, August 3, 2010, Tim Mackinnon <[hidden email]> wrote:
>> Guys - this is my first attempt at a contribution - and I'm not sure how literally to take the advice on "how to contribute to Pharo" for a small change. Should I create an issue, and post it here (happy to do that, but wondered if conversation might be useful first as I'm new to this).
>>
>> Given that I'm not sure what the relationship between eCompletion and oCompletion is (someone mentioned the latter is built on top of the former?) - so maybe I'm barking up the wrong tree, however I was impressed with how much quicker Lucas' Hudson built pharo image was with eCompletion so I've been trying that for a few days (although I've noticed some mails on oCompletion but haven't gone back to retry it).
>>
>> Anyway - I have attached a change set that changes how smart characters work - instead of turning them off because half of the time they do the wrong thing for me and I madly press delete, I wanted to preserve the other half of the time when I'm entering new code and they give me a helpful template.
>>
>> My proposed fix is for the following scenario - if I go to add an extra bracket around an expression (becuase I later realise that I need to designate a keyword expression) I get two brackets - and then I backspace and they both go, so then I do it again and press delete... Instead I think there is a heuristic which says that says if you type a smart character with the cursor next to a non-whitespace item, you probably don't want the matching character. e.g.
>>
>> 5 max: 4 > 3 ifTrue: [] {cursor here} - and I click next to the 4 (or the 5) to put the bracket and I get 2, and I really only want one.
>>
>> My patch tries to address this.
>>
>> I also didn't see any test cases for this stuff (and possibly some could be written - should I try to do that too?).
>>
>> Tim
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>

> Hi Tim,
>
> I've integrated your changes. I chose a slightly simpler
> implementation and slightly different behavior (I think) that I
> interpreted from your code as "do not complete smart characters if
> there is no separator and not the begin or the end of the text to
> either side of the cursor". TextMate seems to do that too.
>
> Lukas
>
> On 3 August 2010 12:21, Lukas Renggli <[hidden email]> wrote:
>> Hi Tim,
>>
>> Thank you for the contribution. I will definitely look at it as soon
>> as I get access to a computer  again (i am a few days away right  
>> now).
>>
>> Testing this would be definitely cool, especially given all the edge
>> cases. It is certainly testable, but kind of tricky to setup
>> everything.
>>
>> Lukas
>>
>> On Tuesday, August 3, 2010, Tim Mackinnon <[hidden email]>  
>> wrote:
>>> Guys - this is my first attempt at a contribution - and I'm not  
>>> sure how literally to take the advice on "how to contribute to  
>>> Pharo" for a small change. Should I create an issue, and post it  
>>> here (happy to do that, but wondered if conversation might be  
>>> useful first as I'm new to this).
>>>
>>> Given that I'm not sure what the relationship between eCompletion  
>>> and oCompletion is (someone mentioned the latter is built on top  
>>> of the former?) - so maybe I'm barking up the wrong tree, however  
>>> I was impressed with how much quicker Lucas' Hudson built pharo  
>>> image was with eCompletion so I've been trying that for a few days  
>>> (although I've noticed some mails on oCompletion but haven't gone  
>>> back to retry it).
>>>
>>> Anyway - I have attached a change set that changes how smart  
>>> characters work - instead of turning them off because half of the  
>>> time they do the wrong thing for me and I madly press delete, I  
>>> wanted to preserve the other half of the time when I'm entering  
>>> new code and they give me a helpful template.
>>>
>>> My proposed fix is for the following scenario - if I go to add an  
>>> extra bracket around an expression (becuase I later realise that I  
>>> need to designate a keyword expression) I get two brackets - and  
>>> then I backspace and they both go, so then I do it again and press  
>>> delete... Instead I think there is a heuristic which says that  
>>> says if you type a smart character with the cursor next to a non-
>>> whitespace item, you probably don't want the matching character.  
>>> e.g.
>>>
>>> 5 max: 4 > 3 ifTrue: [] {cursor here} - and I click next to the 4  
>>> (or the 5) to put the bracket and I get 2, and I really only want  
>>> one.
>>>
>>> My patch tries to address this.
>>>
>>> I also didn't see any test cases for this stuff (and possibly some  
>>> could be written - should I try to do that too?).
>>>
>>> Tim
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project