[Pharo-project] ocompletion usability
Hi, OCompletion certainly improved the coding experience in Pharo. But, I have a couple of usability suggestions with OCompletion to make it better. It would be great if someone (Romain? :)) could act on them: 1. Right now, OCompletion is triggered both by Tab and by Enter. It should be only Tab. Here is the reason. When I have a cascade, I want to have the methods starting from the next line, like this: browser mondrian title: 'Something'; painting: [:view ... ] So, after I type browser mondrian, I naturally want to press Enter. However, there exists a method called mondrianAnnounce:, and when I press Enter it gets filled in. So, the intent of Enter should be similar to that of Space: just as a whitespace. Tab is a good choice for triggering the completion because we basically only use Tabs only in a new line where the completion does not apply. 2. When no completion is offered and I press tab, I do get some list. Why is this not offered by default? Is it because it is slower? Is it because it is the regular ECompletion and that is not useful? 3. The completion is triggered only when typing, but not when removing characters. I believe it would be better if it followed me all the time. 4. When I want to navigate through the offered list using the down arrow the look changes and the items become wider. In fact, the same appears when I force completion by pressing Tab, so this leads me to believe that the change in the look is given by the change from O to E completion. The look should remain the same. Cheers, Doru -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."
Hi Doru, On Nov 30, 2009, at 9:56 AM, Tudor Girba wrote:
Hi,
OCompletion certainly improved the coding experience in Pharo. But, I have a couple of usability suggestions with OCompletion to make it better. It would be great if someone (Romain? :)) could act on them:
1. Right now, OCompletion is triggered both by Tab and by Enter. It should be only Tab.
Here is the reason. When I have a cascade, I want to have the methods starting from the next line, like this: browser mondrian title: 'Something'; painting: [:view ... ]
So, after I type browser mondrian, I naturally want to press Enter. However, there exists a method called mondrianAnnounce:, and when I press Enter it gets filled in. So, the intent of Enter should be similar to that of Space: just as a whitespace. Tab is a good choice for triggering the completion because we basically only use Tabs only in a new line where the completion does not apply.
Well, the completion with enter was requested by a few people, so we should reach a consensus.
2. When no completion is offered and I press tab, I do get some list. Why is this not offered by default? Is it because it is slower? Is it because it is the regular ECompletion and that is not useful?
It is the regular ECompletion, which is slower, and less useful.
3. The completion is triggered only when typing, but not when removing characters. I believe it would be better if it followed me all the time.
Good point!
4. When I want to navigate through the offered list using the down arrow the look changes and the items become wider. In fact, the same appears when I force completion by pressing Tab, so this leads me to believe that the change in the look is given by the change from O to E completion. The look should remain the same.
I thought about it and concluded that it may be good to differentiate them. As for the tab/enter issue, different people think differently. That's why we should reach a consensus on these two issues, so that I can decide whether I should remove these two features :-). Cheers, Romain
Cheers, Doru
-- www.tudorgirba.com
"If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://www.inf.unisi.ch/phd/robbes
Hi all! 2009/11/30 Romain Robbes <romain.robbes@lu.unisi.ch>:
2. When no completion is offered and I press tab, I do get some list. Why is this not offered by default? Is it because it is slower? Is it because it is the regular ECompletion and that is not useful?
It is the regular ECompletion, which is slower, and less useful.
OCompletion is great, but I think it will be far better if the regular ECompletion list appears automatically in case OCompletion can't offer any suggestions. It's very useful to see ECompletion list in case you've just forgotten the right method name or class name. But now I forced to press backspace to return to the point at which OCompletion still can give suggestions, press down arrow just to keep ECompletion window opened and then continue to type. Cheers, George
On Nov 30, 2009, at 10:58 AM, George Herolyants wrote:
Hi all!
2009/11/30 Romain Robbes <romain.robbes@lu.unisi.ch>:
2. When no completion is offered and I press tab, I do get some list. Why is this not offered by default? Is it because it is slower? Is it because it is the regular ECompletion and that is not useful?
It is the regular ECompletion, which is slower, and less useful.
OCompletion is great, but I think it will be far better if the regular ECompletion list appears automatically in case OCompletion can't offer any suggestions. It's very useful to see ECompletion list in case you've just forgotten the right method name or class name. But now I forced to press backspace to return to the point at which OCompletion still can give suggestions, press down arrow just to keep ECompletion window opened and then continue to type.
Hi George, in that case, I think pressing tab even if the list is empty should work, unless I misunderstood. Romain
Cheers, George
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://www.inf.unisi.ch/phd/robbes
2009/11/30 Romain Robbes <romain.robbes@lu.unisi.ch>:
Hi George,
in that case, I think pressing tab even if the list is empty should work, unless I misunderstood.
Oh, thanks for the answer and sorry :) I really missed that. I tried to use Ctrl+Tab to invoke ECompletion list (by analogy with Ctrl+Space that invokes OCompletion), but I didn't try just Tab :). Thanks! George
Hi Romain,
1. Right now, OCompletion is triggered both by Tab and by Enter. It should be only Tab.
Here is the reason. When I have a cascade, I want to have the methods starting from the next line, like this: browser mondrian title: 'Something'; painting: [:view ... ]
So, after I type browser mondrian, I naturally want to press Enter. However, there exists a method called mondrianAnnounce:, and when I press Enter it gets filled in. So, the intent of Enter should be similar to that of Space: just as a whitespace. Tab is a good choice for triggering the completion because we basically only use Tabs only in a new line where the completion does not apply.
Well, the completion with enter was requested by a few people, so we should reach a consensus.
I believe that the scenario presented above is a reasonable and not uncommon one. Right now, I have to get from an subconscious state of typing to a conscious one to get myself to press Space before Enter. And I do not see the gain of having two keys doing the same thing.
2. When no completion is offered and I press tab, I do get some list. Why is this not offered by default? Is it because it is slower? Is it because it is the regular ECompletion and that is not useful?
It is the regular ECompletion, which is slower, and less useful.
3. The completion is triggered only when typing, but not when removing characters. I believe it would be better if it followed me all the time.
Good point!
4. When I want to navigate through the offered list using the down arrow the look changes and the items become wider. In fact, the same appears when I force completion by pressing Tab, so this leads me to believe that the change in the look is given by the change from O to E completion. The look should remain the same.
I thought about it and concluded that it may be good to differentiate them.
I do not believe that making explicit the internal implementation of the overall completion service is beneficial. In fact, the inconsistency just raises questions and it somehow makes me feel as if I am breaking something. If the question of the choice between the E and O appearance arises, my preference is for the colors and appearance of OCompletion (I like it that it does not take that much space and the colors are less intrusive). Cheers, Doru
As for the tab/enter issue, different people think differently. That's why we should reach a consensus on these two issues, so that I can decide whether I should remove these two features :-).
Cheers, Romain
Cheers, Doru
-- www.tudorgirba.com
"If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://www.inf.unisi.ch/phd/robbes
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "It's not how it is, it is how we see it."
Hi Romain, On 30 Nov 2009, at 12:09, Tudor Girba wrote:
Well, the completion with enter was requested by a few people, so we should reach a consensus.
I believe that the scenario presented above is a reasonable and not uncommon one. Right now, I have to get from an subconscious state of typing to a conscious one to get myself to press Space before Enter. And I do not see the gain of having two keys doing the same thing.
I second Doru's comment. Hitting the enter key should not trigger completion. If some people like it, maybe it could be a preference, but I was thinking there was a bug in the latest versions because it was... bugging me :-) Apart from that, I really like OCompletion and get annoyed when working again in an environment that does not have it. So keep up the good work! ---------------------------- Johan Brichau johan.brichau@uclouvain.be
Doru I'm on the cfocnused guy.... So indeed a nice preference now that we have Setting would be good. Stef On Nov 30, 2009, at 12:09 PM, Tudor Girba wrote:
Hi Romain,
1. Right now, OCompletion is triggered both by Tab and by Enter. It should be only Tab.
Here is the reason. When I have a cascade, I want to have the methods starting from the next line, like this: browser mondrian title: 'Something'; painting: [:view ... ]
So, after I type browser mondrian, I naturally want to press Enter. However, there exists a method called mondrianAnnounce:, and when I press Enter it gets filled in. So, the intent of Enter should be similar to that of Space: just as a whitespace. Tab is a good choice for triggering the completion because we basically only use Tabs only in a new line where the completion does not apply.
Well, the completion with enter was requested by a few people, so we should reach a consensus.
I believe that the scenario presented above is a reasonable and not uncommon one. Right now, I have to get from an subconscious state of typing to a conscious one to get myself to press Space before Enter. And I do not see the gain of having two keys doing the same thing.
2. When no completion is offered and I press tab, I do get some list. Why is this not offered by default? Is it because it is slower? Is it because it is the regular ECompletion and that is not useful?
It is the regular ECompletion, which is slower, and less useful.
3. The completion is triggered only when typing, but not when removing characters. I believe it would be better if it followed me all the time.
Good point!
4. When I want to navigate through the offered list using the down arrow the look changes and the items become wider. In fact, the same appears when I force completion by pressing Tab, so this leads me to believe that the change in the look is given by the change from O to E completion. The look should remain the same.
I thought about it and concluded that it may be good to differentiate them.
I do not believe that making explicit the internal implementation of the overall completion service is beneficial. In fact, the inconsistency just raises questions and it somehow makes me feel as if I am breaking something.
If the question of the choice between the E and O appearance arises, my preference is for the colors and appearance of OCompletion (I like it that it does not take that much space and the colors are less intrusive).
Cheers, Doru
As for the tab/enter issue, different people think differently. That's why we should reach a consensus on these two issues, so that I can decide whether I should remove these two features :-).
Cheers, Romain
Cheers, Doru
-- www.tudorgirba.com
"If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://www.inf.unisi.ch/phd/robbes
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"It's not how it is, it is how we see it."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
While someone is looking into usability, is there a way to also complete for common tokens, or better global names? A very annoying example is the completion offered while trying to use the Transcript, it always offers TranscriptTest, instead of Transcript, which is probably the case because it is not take names of globals into account. And since "printf"-style debugging seems to be the only way to debug concurrent code, that is something I use very frequently... Best regards Stefan On 30 Nov 2009, at 09:56, Tudor Girba wrote:
Hi,
OCompletion certainly improved the coding experience in Pharo. But, I have a couple of usability suggestions with OCompletion to make it better. It would be great if someone (Romain? :)) could act on them:
1. Right now, OCompletion is triggered both by Tab and by Enter. It should be only Tab.
Here is the reason. When I have a cascade, I want to have the methods starting from the next line, like this: browser mondrian title: 'Something'; painting: [:view ... ]
So, after I type browser mondrian, I naturally want to press Enter. However, there exists a method called mondrianAnnounce:, and when I press Enter it gets filled in. So, the intent of Enter should be similar to that of Space: just as a whitespace. Tab is a good choice for triggering the completion because we basically only use Tabs only in a new line where the completion does not apply.
2. When no completion is offered and I press tab, I do get some list. Why is this not offered by default? Is it because it is slower? Is it because it is the regular ECompletion and that is not useful?
3. The completion is triggered only when typing, but not when removing characters. I believe it would be better if it followed me all the time.
4. When I want to navigate through the offered list using the down arrow the look changes and the items become wider. In fact, the same appears when I force completion by pressing Tab, so this leads me to believe that the change in the look is given by the change from O to E completion. The look should remain the same.
Cheers, Doru
-- www.tudorgirba.com
"If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525
Good point. I also need Transcript once in a while, and didn't realize that was the reason it was missing! Thanks, Romain On Nov 30, 2009, at 10:45 AM, Stefan Marr wrote:
While someone is looking into usability, is there a way to also complete for common tokens, or better global names?
A very annoying example is the completion offered while trying to use the Transcript, it always offers TranscriptTest, instead of Transcript, which is probably the case because it is not take names of globals into account.
And since "printf"-style debugging seems to be the only way to debug concurrent code, that is something I use very frequently...
Best regards Stefan
On 30 Nov 2009, at 09:56, Tudor Girba wrote:
Hi,
OCompletion certainly improved the coding experience in Pharo. But, I have a couple of usability suggestions with OCompletion to make it better. It would be great if someone (Romain? :)) could act on them:
1. Right now, OCompletion is triggered both by Tab and by Enter. It should be only Tab.
Here is the reason. When I have a cascade, I want to have the methods starting from the next line, like this: browser mondrian title: 'Something'; painting: [:view ... ]
So, after I type browser mondrian, I naturally want to press Enter. However, there exists a method called mondrianAnnounce:, and when I press Enter it gets filled in. So, the intent of Enter should be similar to that of Space: just as a whitespace. Tab is a good choice for triggering the completion because we basically only use Tabs only in a new line where the completion does not apply.
2. When no completion is offered and I press tab, I do get some list. Why is this not offered by default? Is it because it is slower? Is it because it is the regular ECompletion and that is not useful?
3. The completion is triggered only when typing, but not when removing characters. I believe it would be better if it followed me all the time.
4. When I want to navigate through the offered list using the down arrow the look changes and the items become wider. In fact, the same appears when I force completion by pressing Tab, so this leads me to believe that the change in the look is given by the change from O to E completion. The look should remain the same.
Cheers, Doru
-- www.tudorgirba.com
"If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://www.inf.unisi.ch/phd/robbes
On 30 nov. 2009, at 05:56, Tudor Girba wrote:
Hi,
OCompletion certainly improved the coding experience in Pharo. But, I have a couple of usability suggestions with OCompletion to make it better. It would be great if someone (Romain? :)) could act on them:
1. Right now, OCompletion is triggered both by Tab and by Enter. It should be only Tab.
Here is the reason. When I have a cascade, I want to have the methods starting from the next line, like this: browser mondrian title: 'Something'; painting: [:view ... ]
So, after I type browser mondrian, I naturally want to press Enter. However, there exists a method called mondrianAnnounce:, and when I press Enter it gets filled in. So, the intent of Enter should be similar to that of Space: just as a whitespace. Tab is a good choice for triggering the completion because we basically only use Tabs only in a new line where the completion does not apply.
I concur with Doru especially on this one. I think the best to do is to have some kind of settings (with the new settings package) so that users can customize their own key bindings (or, failing that because key bindings is not easy for now, a setting to enable/disable the 'enter' or the 'tab' keybinding) On the minor side of wish list, it would be great for me if I had completion of pragmas :)
2. When no completion is offered and I press tab, I do get some list. Why is this not offered by default? Is it because it is slower? Is it because it is the regular ECompletion and that is not useful?
3. The completion is triggered only when typing, but not when removing characters. I believe it would be better if it followed me all the time.
4. When I want to navigate through the offered list using the down arrow the look changes and the items become wider. In fact, the same appears when I force completion by pressing Tab, so this leads me to believe that the change in the look is given by the change from O to E completion. The look should remain the same.
Cheers, Doru
-- www.tudorgirba.com
"If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
I concur with Doru especially on this one. I think the best to do is to have some kind of settings (with the new settings package) so that users can customize their own key bindings (or, failing that because key bindings is not easy for now, a setting to enable/disable the 'enter' or the 'tab' keybinding)
Is that settings package included by default? Romain -- Romain Robbes http://www.inf.unisi.ch/phd/robbes
On 30 nov. 2009, at 09:45, Romain Robbes wrote:
I concur with Doru especially on this one. I think the best to do is to have some kind of settings (with the new settings package) so that users can customize their own key bindings (or, failing that because key bindings is not easy for now, a setting to enable/disable the 'enter' or the 'tab' keybinding)
Is that settings package included by default?
I think it is scheduled for inclusion in 1.1. See the latest post of Alain and his slice in the inbox. -- Simon
On Nov 30, 2009, at 1:45 PM, Romain Robbes wrote:
I concur with Doru especially on this one. I think the best to do is to have some kind of settings (with the new settings package) so that users can customize their own key bindings (or, failing that because key bindings is not easy for now, a setting to enable/disable the 'enter' or the 'tab' keybinding)
Is that settings package included by default?
Yes and more important its architecture make sure now that you can load your code without setting loaded. This also means that in the future you could load your code and we could remove Setting for shrinking purpose. Thanks Alain :) and lukas for putting a bit more pressure
Romain -- Romain Robbes http://www.inf.unisi.ch/phd/robbes
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (7)
-
George Herolyants -
Johan Brichau -
Romain Robbes -
Simon Denier -
Stefan Marr -
Stéphane Ducasse -
Tudor Girba