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

>
>
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Hi all!
>
> 2009/11/30 Romain Robbes <[hidden email]>:
>
>>> 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.

> 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
>> [hidden email]
>> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> Romain Robbes
> http://www.inf.unisi.ch/phd/robbes
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> --
>> Romain Robbes
>> http://www.inf.unisi.ch/phd/robbes
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> Romain
> --
> Romain Robbes
> http://www.inf.unisi.ch/phd/robbes
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project