[Pharo-project] 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
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 <tamackinnon@gmail.com> 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 <renggli@gmail.com> 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 <tamackinnon@gmail.com> 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
I'll look forward to seeing how you did it (and I agree - textmate is probably a reasonably benchmark) thanks, Tim On 5 Aug 2010, at 17:50, Lukas Renggli wrote:
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 <renggli@gmail.com> 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 <tamackinnon@gmail.com> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thanks tim.
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).
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 Now since this is for an external package you can add lukas on the field and he will get notified.
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>
Excellent improving the interface to code is key. Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
If you register as a developper on the Google code website, you could modify the wiki by yourself ;-) 2010/8/3 Tim Mackinnon <tamackinnon@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr 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/
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 <tamackinnon@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
tx! On Aug 3, 2010, at 1:35 PM, Tim Mackinnon wrote:
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 <tamackinnon@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Lukas Renggli -
Serge Stinckwich -
Stéphane Ducasse -
Tim Mackinnon