I'm trying to make an autocompletion widget that can complete words or 
phrases.
The e/ocompletion frameworks are very oriented to smalltalk syntax, 
which is not what I want; also, they work on TextMorph's, whereas 
StringMorph seemed more natural for what I want since there's only a 
single line.

I've been trying to understand how editing goes, and it seems pretty 
convoluted.  Just for StringMorph:
* when you want to edit, a new morph, StringMorphEditor, pops up in 
front of the StringMorph.
* the StringMorphEditor uses the TextMorphEditor, with does all the 
paragraph composition.
StringMorphEditor must undo that.  TextMorphEditor includes a reference 
(morph instance variable) back to the StringMorphEditor.
* StringMorphEditor is a subclass of TextMorph.
* TextMorphEditor is a subclass of ParagraphEditor, an ST80 remnant.
* Both the MorphEditors have paragraph objects, which give the layout of 
the text on the screen.  I think the 2 editors have 2 different objects, 
but I'm not sure.

TextMorph's have many of the same features: there is a separate editor 
object, and they end up using ST80 code.

This was in a 3.10 image.

So, are there reasons for this division of labor, or did they simply 
evolve trying to build new functionality on top of old functionality?  
My understanding of the morphic spirit led me to expect that the basic 
objects, StringMorph and TextMorph, would be handling the user 
interaction much more directly.  What I see has more of an MVC flavor, 
though it's more complicated than that.

I can imagine that the distinction between the Morph's and MorphEditors 
arose out of desire to keep display only widgets light-weight, but other 
than that I'm puzzled.

I thought I was going to make the completion widget by subclassing 
StringMorph and then implementing logic directly in the morphic event 
handler methods.  I see that the existing widgets do not implement 
"vanilla" editing that way, and that the best developed completion 
frameworks also do not take this approach (they also use ParagraphEditor 
or subclasses).  All of which makes me wonder what the best strategy is.

I appreciate any guidance or insights you can offer.

Ross Boylan

P.S. StringMorphEditor>>keyStroke: has this introductory comment:
    "This is hugely inefficient, but it seems to work, and it's unlikely 
it will ever need
    to be any more efficient -- it's only intended to edit single-line 
strings."
My concern is with human comprehensibillity and  design elegance and 
integrity rather than run-time efficiency.