Hi,

> On 04 Oct 2015, at 23:53, Peter Uhnák <[email protected]> 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 
> <http://www.typescriptlang.org/Playground> )
> 
> So if you have any thoughts/feedback/whatnot on this matter, I would greatly 
> appreciate it.
> 
> Peter
> 

Reply via email to