Feature request: immediately show selectors from "instance creation" after a class name

[j4yk]

As a developer, when I type a concrete class name and press space, I would like to see the selectors from the "instance creation" protocol (class side) proposed immediately. It would save me opening a browser, selecting the class side, and looking up the names of those methods because I often forget them.

The more specific methods (further down in the class hierarchy), specialized constructors, should come first, then the more general ones. Proposing the constructors from Object (#new, #new:, #newFrom:) is obviously not so important. You could investigate about not showing the proposal if there are no specialized constructors.

More generally, all methods from the class side could be proposed immediately. But constructor selectors are probably the most common continuation after a class name.

[LinqLover]

More generally, all methods from the class side could be proposed immediately.

afaik this is already done at the moment? See #guessGlobal:.

I would be careful when making heuristic assumptions such as "'instance creation' selectors are most popular". Other users might use classes for other things - for example, I am using #newSubclass all day. And heuristics can make the implementation much more chaotic.

But some preferences for the behavior you propose might be interesting :)

[j4yk]

Well, afaik no completion ever pops up before typing at least one character.

Moreover, I could not find my sought constructor after typing "o" because "on:withName:" did not even make it on the first page of the proposal.

[LinqLover]

Well, afaik no completion ever pops up before typing at least one character.

Unless you press space :-)

Moreover, I could not find my sought constructor after typing "o" because "on:withName:" did not even make it on the first page of the proposal.

I can reproduce this. We already have some type-guessing logic, but the prioritization logic appears not to respect it, it only performs fuzzy matching. ECModel >> #addToEntries: may be a good starting point.

@MrModder Are we on the right track? Did you already have any plans to enhance this?

[j4yk]

Well, afaik no completion ever pops up before typing at least one character.

Unless you press space :-)

Never saw that happen. Opening a new workspace, typing ToolBuilder<space>, nothing happens regarding Autocompletion. Pressing space a few more times also does not bring it up.

[LinqLover]

Well, afaik no completion ever pops up before typing at least one character.

Unless you press space :-)

Never saw that happen. Opening a new workspace, typing ToolBuilder, nothing happens regarding Autocompletion. Pressing space a few more times also does not bring it up.

Aw, sorry, I meant <cmd>space! GitHub censored that as an XML tag ^^

[j4yk]

Cmd-space extends the text selection (word, line, in brackets, etc).
But Ctrl-space works :-) (Windows, with preferences as Alt = Cmd)

Does not list anything useful for my described use case though. Only the variables of the receiver class.

[LinqLover]

Well, I confused the preferences :-)

[LeonMatthes]

Suggesting methods from the instance creation category first sounds like a valuable idea. I do however agree with @LinqLover , that heuristics like that can lead to a very convoluted implementation over time, which is why I would be reluctant to add a feature as specific as this.
A more generic approach could be to weigh functions higher if they are from a category that in the past has been used a lot (we already save the completion history in ECHistory, so that could be expanded upon).
This would allow for different users to train their Autocompletion for their specific use case and could help solve this problem and any similar problems where only functions from one category are used a lot on a particular class.

However, I am currently not using Squeak in my day to day work and don't have the time to implement a feature like that. If any of you want to create a PR for this, I'd of course be happy to review and merge it. Keep in mind performance considerations of adding another metric though. The Autocompletion can already take quite a while to open up, adding another weight function is likely to increase that time even further. So at least making it an option would be an absolute necessity.
I never got around to optimizing the suggestion algorithm or to making it a background process, so any lag in the Autocompletion can be felt immediately whilst typing. That was highest on my todo list before I had to focus my time on other projects.

[LinqLover]

Maybe we should also provide a hook to overwrite weighs by a certain model. See also Create new trait in Browser.