Smalltalk › Pharo › Pharo Smalltalk Developers

Better Code Completion

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

14 messages Options

Peter Uhnak

Better Code Completion

This is both rant and list of questions/notes/observations...

...but first of all:

do Smalltalkers not like code completion? Because the one in Pharo is really poor and not only that nobody is doing anything about it, but also nobody is complaining; this leads me to believe that you either

a) don't have the manpower (this is true pretty much always, so no complaints here)

b) don't care about this that much (since you lived without it for 45 years)

at least from the lack of complaining to me it seems that b) is more likely scenario...

But since I do use it, I get annoyed by it quite a bit, especially since I regularly work in IDEs where this thousand times better.

Now I would like to get things moving a bit (or bury it and forget it), so I have couple of questions and would appreciate if someone could provide some feedback.

1. Methods of core/top classes should be deprioritized

Since Object has almost 500 methods whatever I will start typing Object/TClass/TBehavior/... will have a list of answers...

so let's start typing...

Very often I have to type almost full word to see what I want.

Shouldn't the completion follow the inheritance chain? So first it shows me matches from the class itself (especially since it actually knows the type) and only after then it's parents and so on?

3. Or maybe even show the (closest) class that implements it.

So the last two items would have somewhere (beginning or the end) written '(Object)' and the first two '(yourself)' (or the class's name).

2. The window has fixed size, so if I have longer method (as in picture above) I don't see it all.

3. Is middle-of-the word really that often used? See moseIntere<sti>ngEntity above. It feels to me that it just creates a lot of false positives (I have this problem also with inspector btw, so I often have to prefix it with >># or if I see it already lot of <arrow down>, which is annoying)

4. We write tests, however how often have you manually created an instance of a test class by hand? I think they should be either filtered or deprioritized as they create visual clutter. This is probably also true for many other classes such as ConfigurationOf/Manifest/... Nobody instantiates them by hand.

5. How often do you send #abs to a dictionary? Maybe also deprioritize extension methods?

6. If I have already written part of the selector it's impossible to "continue" and add an extra parameter. This is because it doesn't know if I am code completing for dict, or #key.

Maybe different shortcuts? <tab> to code complete on #key, and <shift+tab> to code complete on the previous one... or maybe cycle through them because this can be nested (the currently code completed item would have to be highlighted somehow).

7. So if I don't want to see the above I have to type it manually; which is fine for #at:put: but not for longer words.. (just to find out ten seconds later that I have a stupid typo there).

8. The code completion doesn't show parameter names. This is very helpful because it often reveals what it actually accepts. Now I have to actually look into the code of the method.

Now we can hardly compete with typed languages, but I think there's a lot lot room for improvement.

For comparison from other languages/IDE's.

PhpStorm/PHP

(notice how it shows the whole method if it's longer than the window and doesn't it just clip)

NetBeans/C++

In the picture above it still provides hinting when typing the parameter.

TypeScript playground

(similar to NetBeans)

Also they have in their online playground better and nicer code completion than we have in actual env (http://www.typescriptlang.org/Playground )

So if you have any thoughts/feedback/whatnot on this matter, I would greatly appreciate it.

Peter

Uko2

Re: Better Code Completion

Hi,

On 04 Oct 2015, at 23:53, Peter Uhnák <[hidden email]> wrote:

This is both rant and list of questions/notes/observations...

...but first of all:
do Smalltalkers not like code completion? Because the one in Pharo is really poor and not only that nobody is doing anything about it, but also nobody is complaining; this leads me to believe that you either

a) don't have the manpower (this is true pretty much always, so no complaints here)
b) don't care about this that much (since you lived without it for 45 years)

at least from the lack of complaining to me it seems that b) is more likely scenario...

It’s a). And improvements don’t come from complaints, they come from suggestions, and even more often from contributions. I’ve already asked bout something, but there is no one who has tome to work with code completion.

But since I do use it, I get annoyed by it quite a bit, especially since I regularly work in IDEs where this thousand times better.

Now I would like to get things moving a bit (or bury it and forget it), so I have couple of questions and would appreciate if someone could provide some feedback.

1. Methods of core/top classes should be reprioritized

I am not sure that code completion is based on a real methods that know their class, I think that it’s model is rather a simple set of symbols. Maybe I’m wrong, but if it is the case, it impacts many of the following issues.

Since Object has almost 500 methods whatever I will start typing Object/TClass/TBehavior/... will have a list of answers...

so let's start typing...

<2015-10-04_23:02:50.png>

<2015-10-04_23:03:14.png>

<2015-10-04_23:03:25.png>

Very often I have to type almost full word to see what I want.
Shouldn't the completion follow the inheritance chain? So first it shows me matches from the class itself (especially since it actually knows the type) and only after then it's parents and so on?

3. Or maybe even show the (closest) class that implements it.
So the last two items would have somewhere (beginning or the end) written '(Object)' and the first two '(yourself)' (or the class's name).

2. The window has fixed size, so if I have longer method (as in picture above) I don't see it all.

3. Is middle-of-the word really that often used? See moseIntere<sti>ngEntity above. It feels to me that it just creates a lot of false positives (I have this problem also with inspector btw, so I often have to prefix it with >># or if I see it already lot of <arrow down>, which is annoying)

I actually find it useful sometimes, but also it does not help me much because it’s case sensitive. Also considering the fact that you can easily use Spotter for to lookup, maybe it makes sense to just ignore middle word suggestions.

<2015-10-04_23:07:47.png>

4. We write tests, however how often have you manually created an instance of a test class by hand? I think they should be either filtered or deprioritized as they create visual clutter. This is probably also true for many other classes such as ConfigurationOf/Manifest/... Nobody instantiates them by hand.

You are right. It will be interesting to have some kind of model for that. Because you don’t want to do this for every framework by hand, right? I.e. if I throw away SUnit and start to use something else, I would like to have to same features.

<2015-10-04_23:09:36.png>
5. How often do you send #abs to a dictionary? Maybe also deprioritize extension methods?

Tough to generalize. If I extend something then I definitely use it quite often. Maybe having a “project that you work on” can help in prioritization.

<2015-10-04_23:10:15.png>
6. If I have already written part of the selector it's impossible to "continue" and add an extra parameter. This is because it doesn't know if I am code completing for dict, or #key.
Maybe different shortcuts? <tab> to code complete on #key, and <shift+tab> to code complete on the previous one... or maybe cycle through them because this can be nested (the currently code completed item would have to be highlighted somehow).

I think that there are many limitations because you are editing a text and not ast. Would be nice to have a placeholders like in xCode that allow you to enter parameters one by one after you’ve autocompleted multi-parameter message. But again, for now we are only on text level.

<2015-10-04_23:10:23.png>
7. So if I don't want to see the above I have to type it manually; which is fine for #at:put: but not for longer words.. (just to find out ten seconds later that I have a stupid typo there).

8. The code completion doesn't show parameter names. This is very helpful because it often reveals what it actually accepts. Now I have to actually look into the code of the method.

Again, probably it’s just a symbol, not a method. On the other hand, what should you do if you have multiple implementors. It probably would be useful to have suggestion when method is already there, and you are typing in parameters.

Anyway, if you can contribute any improvement, personaly I’d be grateful.

Cheers.

Uko

Now we can hardly compete with typed languages, but I think there's a lot lot room for improvement.

For comparison from other languages/IDE's.

PhpStorm/PHP
<2015-10-04_22:53:38.png>
(notice how it shows the whole method if it's longer than the window and doesn't it just clip)

NetBeans/C++

<2015-10-04_23:01:09.png>

<2015-10-04_23:01:50.png>
In the picture above it still provides hinting when typing the parameter.

TypeScript playground
<2015-10-04_23:12:12.png>
<2015-10-04_23:12:31.png>
(similar to NetBeans)

Also they have in their online playground better and nicer code completion than we have in actual env (http://www.typescriptlang.org/Playground )

So if you have any thoughts/feedback/whatnot on this matter, I would greatly appreciate it.

Peter

Marcus Denker-4

Re: [Pharo-users] Better Code Completion

In reply to this post by Peter Uhnak

> On 05 Oct 2015, at 08:39, Stephan Eggermont <[hidden email]> wrote:
>
> On 04/10/15 23:53, Peter Uhnák wrote:
>> This is both rant and list of questions/notes/observations...
>>
>> ...but first of all:
>> do Smalltalkers not like code completion? Because the one in Pharo is
>> really poor and not only that nobody is doing anything about it, *but
>> also nobody is complaining*; this leads me to believe that you either
>>
>> a) don't have the manpower (this is true pretty much always, so no
>> complaints here)
>
> Definitely.
> The issue tracker has lots of interesting completion related issues, like https://pharo.fogbugz.com/f/cases/13124/NECContext-needs-plugin-design
>

Yes, and we need to change it to use the AST instead of Shout… that could simplify it a lot.

Marcus

Marcus Denker-4

Re: [Pharo-users] Better Code Completion

In reply to this post by Peter Uhnak

On 04 Oct 2015, at 23:53, Peter Uhnák <[hidden email]> wrote:

This is both rant and list of questions/notes/observations...

...but first of all:
do Smalltalkers not like code completion? Because the one in Pharo is really poor and not only that nobody is doing anything about it, but also nobody is complaining; this leads me to believe that you either

a) don't have the manpower (this is true pretty much always, so no complaints here)

true.

b) don't care about this that much (since you lived without it for 45 years)

at least from the lack of complaining to me it seems that b) is more likely scenario...

I think people know that complaining does not help…

It would be nice to improve this (an 1000 other things, too ;-)

Marcus

Attila Magyar

Re: Better Code Completion

In reply to this post by Peter Uhnak

do Smalltalkers not like code completion? Because the one in Pharo is really poor and not only that nobody is doing anything about it, but also nobody is complaining

Agree, and this can be improved significantly. I see a lots of potential doing precise code completion in the debugger/inspector/workspace based on the runtime information available.

http://forum.world.st/Customised-auto-completion-to-give-priority-to-specific-packages-tp4841003p4844128.html

Once I started digging into NECCompletion (or something like this) but its inner behavior wasn't that trivial to me.

Peter Uhnak

Re: Better Code Completion

> it does not help me much because it’s case sensitive.

add to your startup settings

NECPreferences caseSensitive: false

(or Settings > Code Completion > Case Sensitive)

> just ignore middle word suggestions.

so Dict would match "Identity<Dict>ionary", but not "interdiction"? That sounds good.

> I think that there are many limitations because you are editing a text and not ast. Would be nice to have a placeholders like in xCode that allow you to enter parameters one by one after you’ve autocompleted multi-parameter message.

The highlighter currently uses AST even as I type (if I am not mistaken), so it should be available there, but it surely requires investigation.

I'm not familiar with xCode/Objective-C, but the syntax seem that they wrap methods in brackets [] so you always knows the context of the parameter, no?

> I see a lots of potential doing precise code completion in the debugger/inspector/workspace based on the runtime information available.

Yes, this is a good idea (although iterating on the result of the method can leave you blind again...).

> Once I started digging into NECCompletion (or something like this) but its inner behavior wasn't that trivial to me.

I'm currently going through http://users.dcc.uchile.cl/~rrobbes/p/ASE2008-completion.pdf and http://link.springer.com/article/10.1007/s10515-010-0064-x (dunno if there's non-paywalled link) to get better idea of how it works... and I can already see why there's limited progress :)

> Yes, and we need to change it to use the AST instead of Shout… that could simplify it a lot.

Which makes me wonder whether it would make sense to start something small from scratch instead of trying to force AST into the current one.

But we'll see...

Peter

On Mon, Oct 5, 2015 at 3:35 PM, Attila Magyar <[hidden email]> wrote:

> do Smalltalkers not like code completion? Because the one in Pharo is
> really poor and not only that nobody is doing anything about it, but also
> nobody is complaining

Agree, and this can be improved significantly. I see a lots of potential
doing precise code completion in the debugger/inspector/workspace based on
the runtime information available.

http://forum.world.st/Customised-auto-completion-to-give-priority-to-specific-packages-tp4841003p4844128.html

Once I started digging into NECCompletion (or something like this) but its
inner behavior wasn't that trivial to me.

--
View this message in context: http://forum.world.st/Better-Code-Completion-tp4853548p4853703.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Peter Uhnak

Re: Better Code Completion

> Yes, and we need to change it to use the AST instead of Shout… that could simplify it a lot.

Which also means that I have to finally learn the AST...

I found this https://marcusdenker.de/publications/Bera13a-OpalIWST.pdf or do we have something dedicated specifically to the AST? (Some nice overview.)

stepharo

Re: [Pharo-users] Better Code Completion

In reply to this post by Marcus Denker-4

marcus this is about completion not syntax hilighting and the logic can
be tricky.
The student that was planning to work on it used a statistcal model that
shows that it was much better than the default eclipse one.
Now he just left.

Stef

Le 5/10/15 09:25, Marcus Denker a écrit :

>> On 05 Oct 2015, at 08:39, Stephan Eggermont <[hidden email]> wrote:
>>
>> On 04/10/15 23:53, Peter Uhnák wrote:
>>> This is both rant and list of questions/notes/observations...
>>>
>>> ...but first of all:
>>> do Smalltalkers not like code completion? Because the one in Pharo is
>>> really poor and not only that nobody is doing anything about it, *but
>>> also nobody is complaining*; this leads me to believe that you either
>>>
>>> a) don't have the manpower (this is true pretty much always, so no
>>> complaints here)
>> Definitely.
>> The issue tracker has lots of interesting completion related issues, like https://pharo.fogbugz.com/f/cases/13124/NECContext-needs-plugin-design
>>
> Yes, and we need to change it to use the AST instead of Shout… that could simplify it a lot.
>
> Marcus
>
>
>

Uko2

Re: [Pharo-users] Better Code Completion

> On 05 Oct 2015, at 22:23, stepharo <[hidden email]> wrote:
>
> marcus this is about completion not syntax hilighting and the logic can be tricky.
> The student that was planning to work on it used a statistcal model that shows that it was much better than the default eclipse one.
> Now he just left.

He was from Delft :).

The idea to rely on sat can help you to understand whether you are typing a parameter (variable, literal) or a message, and whether it is the beginning of a new message or a continuation of a keyword one.

Uko

P.S. I’m not AST expert, but this is how I understand some things

>
> Stef
>
> Le 5/10/15 09:25, Marcus Denker a écrit :
>>> On 05 Oct 2015, at 08:39, Stephan Eggermont <[hidden email]> wrote:
>>>
>>> On 04/10/15 23:53, Peter Uhnák wrote:
>>>> This is both rant and list of questions/notes/observations...
>>>>
>>>> ...but first of all:
>>>> do Smalltalkers not like code completion? Because the one in Pharo is
>>>> really poor and not only that nobody is doing anything about it, *but
>>>> also nobody is complaining*; this leads me to believe that you either
>>>>
>>>> a) don't have the manpower (this is true pretty much always, so no
>>>> complaints here)
>>> Definitely.
>>> The issue tracker has lots of interesting completion related issues, like https://pharo.fogbugz.com/f/cases/13124/NECContext-needs-plugin-design
>>>
>> Yes, and we need to change it to use the AST instead of Shout… that could simplify it a lot.
>>
>> Marcus
>>
>>
>>
>
>

stepharo

Re: [Pharo-users] Better Code Completion

Le 5/10/15 22:27, Yuriy Tymchuk a écrit :
>> On 05 Oct 2015, at 22:23, stepharo <[hidden email]> wrote:
>>
>> marcus this is about completion not syntax hilighting and the logic can be tricky.
>> The student that was planning to work on it used a statistcal model that shows that it was much better than the default eclipse one.
>> Now he just left.
> He was from Delft :).
>
> The idea to rely on sat can help you to understand whether you are typing a parameter (variable, literal) or a message, and whether it is the beginning of a new message or a continuation of a keyword one.

ah ok then.

>
> Uko
>
> P.S. I’m not AST expert, but this is how I understand some things
>
>> Stef
>>
>> Le 5/10/15 09:25, Marcus Denker a écrit :
>>>> On 05 Oct 2015, at 08:39, Stephan Eggermont <[hidden email]> wrote:
>>>>
>>>> On 04/10/15 23:53, Peter Uhnák wrote:
>>>>> This is both rant and list of questions/notes/observations...
>>>>>
>>>>> ...but first of all:
>>>>> do Smalltalkers not like code completion? Because the one in Pharo is
>>>>> really poor and not only that nobody is doing anything about it, *but
>>>>> also nobody is complaining*; this leads me to believe that you either
>>>>>
>>>>> a) don't have the manpower (this is true pretty much always, so no
>>>>> complaints here)
>>>> Definitely.
>>>> The issue tracker has lots of interesting completion related issues, like https://pharo.fogbugz.com/f/cases/13124/NECContext-needs-plugin-design
>>>>
>>> Yes, and we need to change it to use the AST instead of Shout… that could simplify it a lot.
>>>
>>> Marcus
>>>
>>>
>>>
>>
>
>

Marcus Denker-4

Re: Better Code Completion

In reply to this post by Peter Uhnak

On 05 Oct 2015, at 22:12, Peter Uhnák <[hidden email]> wrote:

> Yes, and we need to change it to use the AST instead of Shout… that could simplify it a lot.

Which also means that I have to finally learn the AST...
I found this https://marcusdenker.de/publications/Bera13a-OpalIWST.pdf or do we have something dedicated specifically to the AST? (Some nice overview.)

Not that I know…

Marcus

Nicolai Hess

Re: [Pharo-users] Better Code Completion

In reply to this post by Peter Uhnak

Am 04.10.2015 23:53 schrieb "Peter Uhnák" <[hidden email]>:
>
> This is both rant and list of questions/notes/observations...
>
> ...but first of all:
> do Smalltalkers not like code completion? Because the one in Pharo is really poor and not only that nobody is doing anything about it, but also nobody is complaining; this leads me to believe that you either
>
> a) don't have the manpower (this is true pretty much always, so no complaints here)
> b) don't care about this that much (since you lived without it for 45 years)
>
> at least from the lack of complaining to me it seems that b) is more likely scenario...
>
> But since I do use it, I get annoyed by it quite a bit, especially since I regularly work in IDEs where this thousand times better.

Can you Name one, for a dynamic OO - language?
(Maybe we can borrow some ideas).

>
> Now I would like to get things moving a bit (or bury it and forget it), so I have couple of questions and would appreciate if someone could provide some feedback.
>
> 1. Methods of core/top classes should be deprioritized
>
> Since Object has almost 500 methods whatever I will start typing Object/TClass/TBehavior/... will have a list of answers...

I think this is difficult, even though this classes are big and you don't use most of the methods,

are you sure we dont use some of the methods *often*. Morphic, ComposeableModel or many collection classes, for example.

>
> so let's start typing...
>
>
>
>
>
> Very often I have to type almost full word to see what I want.

This is doesn't happen often to me. It is far from perfect but most of the time I only type a small part and find the correct completion.

> Shouldn't the completion follow the inheritance chain? So first it shows me matches from the class itself (especially since it actually knows the type) and only after then it's parents and so on?

Currently, it only collects all selectors into a set and sorts by matching and length.

We could add the class info and sort by inheritance distance.

This needs some change how sorting is implemented, for now,it is typeless and may need some double dispatching.

>
> 3. Or maybe even show the (closest) class that implements it.
> So the last two items would have somewhere (beginning or the end) written '(Object)' and the first two '(yourself)' (or the class's name).

This needs some additional work too, now the menu text is the actual completion content. But it

shouldn't be that difficult and some code looks like it was intended to work that way.

>
>
> 2. The window has fixed size, so if I have longer method (as in picture above) I don't see it all.
>
> 3. Is middle-of-the word really that often used? See moseIntere<sti>ngEntity above. It feels to me that it just creates a lot of false positives (I have this problem also with inspector btw, so I often have to prefix it with >># or if I see it already lot of <arrow down>, which is annoying)

I often search for "Dictionary" or "Morph" and expect results even if the typed word is not at the beginning, quite often.

>
>
>
> 4. We write tests, however how often have you manually created an instance of a test class by hand? I think they should be either filtered or deprioritized as they create visual clutter. This is probably also true for many other classes such as ConfigurationOf/Manifest/... Nobody instantiates them by hand.

Be careful will statements like "nobody ...."

I do a lot of reviews for pharo issues, and this involves working in workspace and instantiating classes (Yes, Tests, Refactoring, LintRules) most people don't use them this way but by the tools (SUnit, CriticBrowser)

But I do.

>
> 5. How often do you send #abs to a dictionary?

seldom, never? but how could a completion framework detect that?

>
>
> 6. If I have already written part of the selector it's impossible to "continue" and add an extra parameter. This is because it doesn't know if I am code completing for dict, or #key.
> Maybe different shortcuts? <tab> to code complete on #key, and <shift+tab> to code complete on the previous one...

good idea!

(did you know, that there is a shortcut to jump from one message send argument to another (not related to completion, but very helpful). Sadly this is gone or I couldn't find

it in rubrics shortcut handling).

> or maybe cycle through them because this can be nested (the currently code completed item would have to be highlighted somehow).
>
>
> 7. So if I don't want to see the above I have to type it manually; which is fine for #at:put: but not for longer words.. (just to find out ten seconds later that I have a stupid typo there).
>
> 8. The code completion doesn't show parameter names. This is very helpful because it often reveals what it actually accepts. Now I have to actually look into the code of the method.

Yes, I tried to change that for issue "10219 Completion: enter on accept awkwardness", but again, the completion only knows about the methodDict keys, the selector,

not the mehod code. But I would like to change that and test if it is much slow.

>
> Now we can hardly compete with typed languages, but I think there's a lot lot room for improvement.
>
> For comparison from other languages/IDE's.
>
> PhpStorm/PHP
>
> (notice how it shows the whole method if it's longer than the window and doesn't it just clip)
>
> NetBeans/C++
>
>
>
> In the picture above it still provides hinting when typing the parameter.
>
> TypeScript playground
>
>
> (similar to NetBeans)
>
> Also they have in their online playground better and nicer code completion than we have in actual env (http://www.typescriptlang.org/Playground )
>
> So if you have any thoughts/feedback/whatnot on this matter, I would greatly appreciate it.

>
> Peter
>

Uko2

Re: [Pharo-users] Better Code Completion

On 06 Oct 2015, at 09:09, Nicolai Hess <[hidden email]> wrote:

Am 04.10.2015 23:53 schrieb "Peter Uhnák" <[hidden email]>:
>
> This is both rant and list of questions/notes/observations...
>
> ...but first of all:
> do Smalltalkers not like code completion? Because the one in Pharo is really poor and not only that nobody is doing anything about it, but also nobody is complaining; this leads me to believe that you either
>
> a) don't have the manpower (this is true pretty much always, so no complaints here)
> b) don't care about this that much (since you lived without it for 45 years)
>
> at least from the lack of complaining to me it seems that b) is more likely scenario...
>
> But since I do use it, I get annoyed by it quite a bit, especially since I regularly work in IDEs where this thousand times better.

Can you Name one, for a dynamic OO - language?
(Maybe we can borrow some ideas).

Ruby?

I think that RubyMine has to do something with code completion.

Uko

>
> Now I would like to get things moving a bit (or bury it and forget it), so I have couple of questions and would appreciate if someone could provide some feedback.
>
> 1. Methods of core/top classes should be deprioritized
>
> Since Object has almost 500 methods whatever I will start typing Object/TClass/TBehavior/... will have a list of answers...
I think this is difficult, even though this classes are big and you don't use most of the methods,
are you sure we dont use some of the methods *often*. Morphic, ComposeableModel or many collection classes, for example.
>
> so let's start typing...
>
>
>
>
>
> Very often I have to type almost full word to see what I want.
This is doesn't happen often to me. It is far from perfect but most of the time I only type a small part and find the correct completion.

> Shouldn't the completion follow the inheritance chain? So first it shows me matches from the class itself (especially since it actually knows the type) and only after then it's parents and so on?
Currently, it only collects all selectors into a set and sorts by matching and length.
We could add the class info and sort by inheritance distance.
This needs some change how sorting is implemented, for now,it is typeless and may need some double dispatching.

>
> 3. Or maybe even show the (closest) class that implements it.
> So the last two items would have somewhere (beginning or the end) written '(Object)' and the first two '(yourself)' (or the class's name).
This needs some additional work too, now the menu text is the actual completion content. But it
shouldn't be that difficult and some code looks like it was intended to work that way.
>
>
> 2. The window has fixed size, so if I have longer method (as in picture above) I don't see it all.
>
> 3. Is middle-of-the word really that often used? See moseIntere<sti>ngEntity above. It feels to me that it just creates a lot of false positives (I have this problem also with inspector btw, so I often have to prefix it with >># or if I see it already lot of <arrow down>, which is annoying)
I often search for "Dictionary" or "Morph" and expect results even if the typed word is not at the beginning, quite often.

>
>
>
> 4. We write tests, however how often have you manually created an instance of a test class by hand? I think they should be either filtered or deprioritized as they create visual clutter. This is probably also true for many other classes such as ConfigurationOf/Manifest/... Nobody instantiates them by hand.
Be careful will statements like "nobody ...."
I do a lot of reviews for pharo issues, and this involves working in workspace and instantiating classes (Yes, Tests, Refactoring, LintRules) most people don't use them this way but by the tools (SUnit, CriticBrowser)
But I do.

>
> 5. How often do you send #abs to a dictionary?
seldom, never? but how could a completion framework detect that?

>
>
> 6. If I have already written part of the selector it's impossible to "continue" and add an extra parameter. This is because it doesn't know if I am code completing for dict, or #key.
> Maybe different shortcuts? <tab> to code complete on #key, and <shift+tab> to code complete on the previous one...
good idea!
(did you know, that there is a shortcut to jump from one message send argument to another (not related to completion, but very helpful). Sadly this is gone or I couldn't find
it in rubrics shortcut handling).
> or maybe cycle through them because this can be nested (the currently code completed item would have to be highlighted somehow).
>
>
> 7. So if I don't want to see the above I have to type it manually; which is fine for #at:put: but not for longer words.. (just to find out ten seconds later that I have a stupid typo there).
>
> 8. The code completion doesn't show parameter names. This is very helpful because it often reveals what it actually accepts. Now I have to actually look into the code of the method.
Yes, I tried to change that for issue "10219 Completion: enter on accept awkwardness", but again, the completion only knows about the methodDict keys, the selector,
not the mehod code. But I would like to change that and test if it is much slow.

>
> Now we can hardly compete with typed languages, but I think there's a lot lot room for improvement.
>
> For comparison from other languages/IDE's.
>
> PhpStorm/PHP
>
> (notice how it shows the whole method if it's longer than the window and doesn't it just clip)
>
> NetBeans/C++
>
>
>
> In the picture above it still provides hinting when typing the parameter.
>
> TypeScript playground
>
>
> (similar to NetBeans)
>
> Also they have in their online playground better and nicer code completion than we have in actual env (http://www.typescriptlang.org/Playground )
>
> So if you have any thoughts/feedback/whatnot on this matter, I would greatly appreciate it.

>
> Peter
>

Nicolai Hess

Re: [Pharo-users] Better Code Completion

2015-10-06 10:31 GMT+02:00 Yuriy Tymchuk <[hidden email]>:

On 06 Oct 2015, at 09:09, Nicolai Hess <[hidden email]> wrote:

Am 04.10.2015 23:53 schrieb "Peter Uhnák" <[hidden email]>:
>
> This is both rant and list of questions/notes/observations...
>
> ...but first of all:
> do Smalltalkers not like code completion? Because the one in Pharo is really poor and not only that nobody is doing anything about it, but also nobody is complaining; this leads me to believe that you either
>
> a) don't have the manpower (this is true pretty much always, so no complaints here)
> b) don't care about this that much (since you lived without it for 45 years)
>
> at least from the lack of complaining to me it seems that b) is more likely scenario...
>
> But since I do use it, I get annoyed by it quite a bit, especially since I regularly work in IDEs where this thousand times better.

Can you Name one, for a dynamic OO - language?
(Maybe we can borrow some ideas).

Ruby?

I think that RubyMine has to do something with code completion.

Wow, that looks great, do you work with it?

Uko

>
> Now I would like to get things moving a bit (or bury it and forget it), so I have couple of questions and would appreciate if someone could provide some feedback.
>
> 1. Methods of core/top classes should be deprioritized
>
> Since Object has almost 500 methods whatever I will start typing Object/TClass/TBehavior/... will have a list of answers...
I think this is difficult, even though this classes are big and you don't use most of the methods,
are you sure we dont use some of the methods *often*. Morphic, ComposeableModel or many collection classes, for example.
>
> so let's start typing...
>
>
>
>
>
> Very often I have to type almost full word to see what I want.
This is doesn't happen often to me. It is far from perfect but most of the time I only type a small part and find the correct completion.

> Shouldn't the completion follow the inheritance chain? So first it shows me matches from the class itself (especially since it actually knows the type) and only after then it's parents and so on?
Currently, it only collects all selectors into a set and sorts by matching and length.
We could add the class info and sort by inheritance distance.
This needs some change how sorting is implemented, for now,it is typeless and may need some double dispatching.

>
> 3. Or maybe even show the (closest) class that implements it.
> So the last two items would have somewhere (beginning or the end) written '(Object)' and the first two '(yourself)' (or the class's name).
This needs some additional work too, now the menu text is the actual completion content. But it
shouldn't be that difficult and some code looks like it was intended to work that way.
>
>
> 2. The window has fixed size, so if I have longer method (as in picture above) I don't see it all.
>
> 3. Is middle-of-the word really that often used? See moseIntere<sti>ngEntity above. It feels to me that it just creates a lot of false positives (I have this problem also with inspector btw, so I often have to prefix it with >># or if I see it already lot of <arrow down>, which is annoying)
I often search for "Dictionary" or "Morph" and expect results even if the typed word is not at the beginning, quite often.

>
>
>
> 4. We write tests, however how often have you manually created an instance of a test class by hand? I think they should be either filtered or deprioritized as they create visual clutter. This is probably also true for many other classes such as ConfigurationOf/Manifest/... Nobody instantiates them by hand.
Be careful will statements like "nobody ...."
I do a lot of reviews for pharo issues, and this involves working in workspace and instantiating classes (Yes, Tests, Refactoring, LintRules) most people don't use them this way but by the tools (SUnit, CriticBrowser)
But I do.

>
> 5. How often do you send #abs to a dictionary?
seldom, never? but how could a completion framework detect that?

>
>
> 6. If I have already written part of the selector it's impossible to "continue" and add an extra parameter. This is because it doesn't know if I am code completing for dict, or #key.
> Maybe different shortcuts? <tab> to code complete on #key, and <shift+tab> to code complete on the previous one...
good idea!
(did you know, that there is a shortcut to jump from one message send argument to another (not related to completion, but very helpful). Sadly this is gone or I couldn't find
it in rubrics shortcut handling).
> or maybe cycle through them because this can be nested (the currently code completed item would have to be highlighted somehow).
>
>
> 7. So if I don't want to see the above I have to type it manually; which is fine for #at:put: but not for longer words.. (just to find out ten seconds later that I have a stupid typo there).
>
> 8. The code completion doesn't show parameter names. This is very helpful because it often reveals what it actually accepts. Now I have to actually look into the code of the method.
Yes, I tried to change that for issue "10219 Completion: enter on accept awkwardness", but again, the completion only knows about the methodDict keys, the selector,
not the mehod code. But I would like to change that and test if it is much slow.

>
> Now we can hardly compete with typed languages, but I think there's a lot lot room for improvement.
>
> For comparison from other languages/IDE's.
>
> PhpStorm/PHP
>
> (notice how it shows the whole method if it's longer than the window and doesn't it just clip)
>
> NetBeans/C++
>
>
>
> In the picture above it still provides hinting when typing the parameter.
>
> TypeScript playground
>
>
> (similar to NetBeans)
>
> Also they have in their online playground better and nicer code completion than we have in actual env (http://www.typescriptlang.org/Playground )
>
> So if you have any thoughts/feedback/whatnot on this matter, I would greatly appreciate it.

>
> Peter
>