[Pharo-users] Better Code Completion

Nicolai Hess nicolaihess at web.de
Tue Oct 6 03:09:23 EDT 2015


Am 04.10.2015 23:53 schrieb "Peter Uhnák" <i.uhnak at gmail.com>:
>
> 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
<https://pharo.fogbugz.com/f/cases/10219/Completion-enter-on-accept-awkwardness>
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20151006/0cd4e681/attachment.html>


More information about the Pharo-users mailing list