Currently the simple untyped model is used when the receiver is not known.
This could be split into an untyped model with receiver and one without receiver.
As currently the untyped model contains way too many symbols like classes which are usually nonsense when there is a receiver.

Maybe connects to #14 because we would only want to include method names in this list.
But this would mean finding out all possible method names in the image.

I updated Autocompletion during the last several days. Today I wanted to open a new Workspace window. When I hit the first key in it to type something, I get MessageNotUnderstood: UndefinedObject>>model: from Workspace>>createCompletionController. That method references the class ECWorkspaceController, which no longer exists in my image.

The preference is set so that it accesses the undefined binding, so nil becomes the receiver of the model: self message send.

Scenario:

• Open a workspace window
• Start typing something, Autocompletion menu will appear
• Close the workspace window

Now, the Autocompletion menu slowly fades out. However, as it parent has abandoned, I would expect it to abandon immediately.

Scenario:

• Go to Preferences and disable the option #useECompletionInsteadOfOCompletion
• Open a new workspace window
• Type one character into it

Bug:

• MessageNotUnderstood: #currentMenuMorph in ECController returns nil

(Not that I wanted to turn my back on Autocompletion, but I wanted to test downward compatibility of our tool for users who have not yet had the pleasure of this cool package!)

Two related issues:

1. When typing something like Transcript showln: #completio, symbols (here: #completion) are not suggested, but only class names.

2. When typing something like 123<linebreak>#compareSafel, #compareSafely: is suggested correctly, but expanding it inserts placeholders for the arguments (___) even though the symbol was meant to be entered as a symbol indeed.

   (This example may also reveal another usage problem: In this example, I am taking notes in a syntax-highlighting workspace and actually would not expect to continue the expression from the first line in the second line - but unfortunately, this is how Smalltalk works ...) Anyway, I think when the symbol is prefixed with a hash, it should actually also be completed as a symbol.

Wdyt? As far as it concerns my personal usage, this area might be one of my (probably: the) most annoying behavior when working Autocompletion which I otherwise find great :-)

Referring to the extension method #image:at:sourceRect:rule: in AlphaBlendingCanvas (which, btw, is missing the -override suffix in the extension category name), see ced5677#diff-f8e09250df8680dcca55dfd0177755ff:
Could you please provide a short description of this fix? I'd love to see this in Trunk because it shadows the original method version and thus keeps a "removed method" in my Monticello working copy.

Imagine I want to type the following code:
1 to: 5 do: [...].

If I type 1 to and use the autocompletion I get 1 to:. If I now continue typing the d I get several suggestions but not the do: which would be the second part of the to: do: message. But that would be a cool feature.

I tried to search for this repository today using the GitHub search, but could not find it with the terms "autocompletion squeak". Could you please add Squeak somehow in the project description, so that this repository will show up with these search terms?

Currently the Untyped Model uses either the Symbols from the current environment or ALL symbols.
Both are usually not what you want. All symbols are way too many, especially in images that use symbols for anything other than code. But the environment usually contains only class names and not selectors, which is not enough.
So we should implement a custom tracking, that saves all symbols that are currently part of methods. This could be updated whenever a method is compiled.
Open questions:

• What about method deletions? How do we track those?

Type guessing is a very nice feature, but I think in some cases, information about the actual accessed instance could be useful for further type guessing.

There are many quick methods in Squeak (accessors or magic number returns) which are very fast and side-effect-free. We could guess the instance of the last typed expression in some cases and then perform a possible quick method, to "guess" the type of its return value.

One popular scenario might be Autocompletion in Inspector: Do Morph new inspect, then type bounds origin sqr. Currently, there is no suggestion for sqrt, but as Rectangle>>#bounds is quick, it would be possible to find out the type of bounds origin and so to suggest sqrt. It would be even possible to suggest self bounds origin x sqrt etc.

Possible sources for instance guessing

• Globals
• Constants
• Context (see #29)
• Inspector (also added in #29), ObjectExplorer (todo), Workspace, Debugger -- currently, wherever #guessTypeForName: is implemented, an object is determined and then its class returned, which is kind of "informational waste"

Proposed design changes

• In ECContext, introduce #guessInstanceOf:
• In #guessTypeOf:, first check #guessInstanceOf:
  • clean up here and move at least global and constant checks into #guessInstanceOf:
• In #guessInstanceOf: ...
  • check globals and constant
  • check context
  • invoke #guessUnaryInstance:. There, try to guess instance of previous range and lookup latest selector on its class; if is quick, perform it on the latest object and return the result (already spiked this)
• It would be even possible to invoke #respondsTo: for truely late-bound suggestions 🤩 (useful in case of transparent wrappers)
• In all Model classes, replace #guessTypeForName: with #guessObjectForName:

Questions

• I don't get the actual task of the current #guessUnaryAccessorClass: implementation. What does it do? Would it be still relevant after applying this proposal?
• Naming issue: "instance guessing" sounds quite inelaborate
• Is there be any imaginable case where a model could implement #guessTypeForName:, but could not implement #guessObjectForName:? It would be possible to keep the base implementation and forward it to (self guessObjectForName: aString) class

These are only some thoughts by someone who is not deep into the implementation, so I would be very happy about your feedback! So long, best success for your thesis, @MrModder :)

Scenario:

• Preference "include all selectors" is disabled
• Open an inspector, e. g. on a Morph
• Start typing into the right pane
• If you select no instvar, the Autocompletion will suggest e. g. bounds correctly
• But if you select any instvar (for example bounds), bounds will not be suggested -- but instead, origin and corner
• But you can only evaluate bounds, not origin

Reason:

• ECController asks the model for #selectedClassOrMetaClass
• Default implementation of this is #selectedClass
• Inspector>>#selectedClass returns the class of the current selected instvar
• In this case, the selection does not affect the code that can be evaluated

Questions and solution approaches:

• I am wondering whether the only purpose of #selectedClassOrMetaClass is to be used by Autocompletion? At least, it is in the Autocompletion category, but the on the other hand it has many other senders in Browser, Debugger, pp. In general, what differentiates #selectedClassOrMetaClass from #selectedClass? Are there historical reasons?
• For what purpose does Inspector>>#selectedClass return the class of the selected instvar instead of object class?
• If we could freely dispose of #selectedClassOrMetaClass, the solution would be to override it in Inspector to return object class.
• Otherwise, we would probably need another selector?

As the developer of a Squeak Tool, it would be great to have the ability to define my own Autocompletion entries so that for example search bars could have custom fitted Autocompletion support.

Goal:
Define an API that allows TextMorph-model programmers to provide their own entries to the Autocompletion.

Secondary Goal:
Keep the API generic enough, so that anyone could implement the API hooks without instantly adding the Autocompletion as a dependency

Implementation notes
It is already possible to select a custom ECModel subclass, maybe just provide an ECModel subclass that asks the TextMorph-model for the necessary entries

It would be nice if there is no space inserted after autocompletion, because you get extra spaces before '.' and sometimes before other code (if you insert code somewhere), that you must delete manually

Might fix some of the worse completions when typing in the middle of text

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.

Add a big on: Error do: so users don't get debuggers.

After loading 8cc9dfc, Autocompletion will no longer be shown in Debugger (but flashes for a very short time). This can be solved by overriding #wantsToCloseAutocompletion in Inspector as follows:

^ self containingMorphicModels isEmpty

But when I overrided this selector locally, I wondered why not to change the implementation in StringHolder itself, so that all containing morphs are considered in every case? Is there any case where this would be an unwanted behavior?

Currently the roles of the main classes (controller, context, menu and models) are pretty mixed into each other.
They should however all perform just one role, these should be:

Controller
Responsible for directing user input, to open/close the menu and to provide the menu with the appropriate model.
Currently the controller is Smalltalk-specific, there are even subclasses for browsers and workspaces, that provide functionality that should probably belong to the context.

Current sins:
#allowOverriding, #completionAdditionals, keeps a permanent reference to the context

Context
The context should be responsible for detecting in what context Autocompletion was opened.
Is there a receiver? What class is it? etc.
Therefore this should be the first Smalltalk-specific part of the system, not the controller.
The context should then be the first part that the Textfield-Model has controller over, basically deciding whether it is a Smalltalk-Textfield or something else.
This would make it possible to implement #23
The context should therefore also be the one responsible for checking whether it is parsing a method, not the controller.

Possible sin: Contains a reference to the model, not necessarily a problem, but who knows

Model
The Model is responsible for collecting all the entries, storing and filtering them
There should be Smalltalk-specific models as well as general purpose ones.

Current issue: Pretty slow, otherwise the models code is pretty solid.

Menu
The menu is responsible for displaying the model data.
It should be as smalltalk-agnostic as possible.

Current sins: Keeps a permanent reference to the context which it uses to access the model instead of communicating with the model directly.
Refactoring needed to remove the context from the model

While investigating recent issues with the auto enclose functionality in Squeak 6.0Alpha Trunk¹, @j4yk identified some overlapping preferences of Autocompletion related to the term "smart characters". Without having analyzed their functionality and behavior in-depth, I just wanted to note this down here and propose to revise these preferences to address the following concerns:

• Do they add any value in present Squeak that is not available via the default preferences?
• Should they maybe be removed, deprecated, or at least disabled by default to avoid confusing behavior when a user changes the different settings and does not aim the desired goal?

HNY :-)

(Without fiddling around at the Autcompletion implementation,) I recently got the following error message:

ECModel raised an error as clazz was not a class or metaclass object, but a PasteUpMorph.

The error occurred while trying to type a second letter at the end of the following snipped:

(windowTest is an instance variable)

after completing a message, it should be possible to jump to the next argument input (after : ) using tab

Example:

becomes:

instead of:

Would be very useful!

Not sure if this is a bug, but in our project, we want to close the Autocompletion when the containing model has lost its focus. Now, when I type something into this model and the Autocompletion opens under the hand, our model looses the focus in favor of the ECMenuMorph. Thus, our model wants to close the Autocompletion. The ECMenuMorph forwards the focus, but our model still has received a mouse leave event before.

After some spiking, I suppose there is currently no comfortable way to reject any focus for a morph in advance? Maybe this would be a proposal for the inbox? The only other morph class whose instances usually never gains focus is HaloMorph, where the initial event is handled directly in PasteUpMorph>>#filterEvent:for:, so it would be quite ugly to intervene there.

It would be nice to have the ability to create custom entries in the autocompletion that gets suggested and extended if you choose them.
example: in webstorm I have a clg entry in my autocompletion that expands to console.log
Maybe it would be possible to create general entries (e.g. tsl => Transcript showln: ) and for classes and their subclasses (e.g. itf => ifTrue: ifFalse: for the Boolean class)

Match not the whole string, but separated parts too

This is probably caused by ECMenuMorphs>>editor being a WeakArray

Steps to Reproduce

Resize a workspace window and type the following, for example:

Then press tab. I see the following now:

Expected Behavior

The text should be normally displayed as if you had typed the word manually:

Kind regards!

Currently, the type guesser only analyses the method it is started on and a few methods used to access local variables.

Whenever it hits an unknown method, it stops.
Of course, this could be changed to simply start analysis if the return value of the found method.

Problems:

• Only unary methods could be analysed
• How to analyse a method with multiple returns?

Expected Behavior

writing while having selected text should delete the selected text and insert new input at its position

Current Behavior

the selection is deselected and new input is inserted at the front of the selection

Possible Solution

check for selections before handling the input events

Steps to Reproduce

1. write a class name or message name
2. select any character but the first
3. write at least a single character

Context (Environment)

I'm used to this behavior from other text/code editors.
It is useful when replacing e.g. spelling mistakes.

Not sure if this already in: for the case where I'm editing code in the debugger, there is already a lot of type information available. Using this could provide very accurate and helpful completions.

The current protocol for a Model that supports Autocompletion includes the following information:

• #selectedClassOrMetaClass
• CompletionController, specifying
  • #allowOverriding, which indicates whether we want to parse a method or plain code (or does it have any other purpose?)
  • #workspace
• Respecting #29, #completionContext

Almost always when I want to equip a model with a range of cool Squeak features - mainly DoIt & Co., Shout, and Autocompletion - I also need to provide the following details:

• For DoIt & Co., specify #doItReceiver (and respecting #29, #doItContext)
• For Shout, override #aboutToStyle: (or respecting ToolBuilder-Morphic-ct.228, alternatively #aboutToStyle:forMorph:), specifying
  • #selectedClassOrMetaClass:
  • #parseAMethod:
  • #workspace:
  • Respecting Tools-ct.853, #context:

Moreover, many classes already specify #selectedClassOrMetaClass for miscellaneous purposes.

I find there is some protocol duplication. When would a model want different types for DoIt, Shout and Autocompletion? I would welcome a simplification and unification of these protocols!

• As Shout & Autocompletion do not only have a similar semantic, but also use the same parser: Would it be an option to attach the configuration of Autocompletion to the configuration of Shout? You then would only need to overwrite #aboutToStyle:[forMorph:], unless special features like #completionAdditionals are required.
• Hypothetically: Are there any plans to integrate Autocompletion into Squeak? This could possibly simplify the integration into Squeak (as there are some conflicts with the old OCompletion at the moment) and allow you to solve possible design issues like this in a larger context. And it would make happy each Squeak user how did not discover this repo :-) On the other side, the comfort of using a git repo instead of a mailing list would fall away. Just some thoughts ...

when I compile a new method or change an existing one, it should be ranked higher in the Autocompletion list, as it is likely to be used in the near future

Whereas in light themes:

After a given time of inactivity or loosing the focus the autocompletion should close its suggestions.

Scenario:
I have a trait TConsumer with a single method consume: .
I implement a method with a parameter named aConsumer or aTConsumer.

Expected Behavior:
The completion suggests the method consume:, as it guesses the type TConsumer.

Actual Behavior:
No type is guessed