String/TextMorph/Editor --why so complex?

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.

I just realized the update Andreas described yesterday hits one of these
points directly, and others indirectly.
He wrote:
> New Text Editors
> ----------------
> A complete new set of text editors (Editor, TextEditor and
> SmalltalkEditor) are available. They replace TextMorphEditor and break
> one of the last hard links between Morphic and MVC. With the new
> editors it will finally become possible to have Morphic be
> self-contained without the need to rely on portions of MVC.
Ross Boylan wrote:
> .....
> * TextMorphEditor is a subclass of ParagraphEditor, an ST80 remnant.
> ....
> 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.
3.10.1, more precisely, since the changes are in 3.10.2
>
> 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.  
As I understand it, the new code handles everything in morphic, but
still uses helper objects.  That is, it does not handle the editing
within the original morph.
> What I see has more of an MVC flavor, though it's more complicated
> than that.
MVC there was a reference to the approach, so eliminating the ST80
remnant doesn't necessarily change anything.

Ross

On Monday 30 November 2009 03:57:48 am Ross Boylan wrote:
> 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 poked into this framework sometime back to see how it affects multilingual
text. Let me share my understanding and let others step in with corrections:

String - sequence of 8-bit character codes (implied ASCII)
WideString - sequence of 32-bit character codes (implied Unicode 32)
Text - sequence of decorated Strings where decorations could be color, shape,
size.
Paragraph - Text laid out in boxes (alignment, justification, line spacing)

These are string encoding models with no dependencies on renderers/editors. In
practice, it is hard to keep encodings separated from rendering/editing
operations ;-). Refactoring is complicated by the fact editing is tightly
coupled with rendering and layout for text objects, esp. in the case of
multilingual texts.

Pre-morphic Squeak used ParagraphEditor for editing strings
(StringHolderController) and Text/Paragraphs. Editors (controllers) were hard-
bound to these objects.

Morphic uses StringMorph, TextMorph and NewParagraph to render these abstract
collections. Editing operations (like selection, undo) were moved into Editor
class and then extended for handling types of text. So you have
StringMorphEditor for short strings, TextEditor for runs of strings and
SmalltalkEditor for source code. The ability to switch editors is important
for text with complex layouts (e.g. right-to-left, math formula). Eventually,
one should be able to click on the 'pencil' halo icon to bring up a suitable
editor.

I hope Squeak evolves to support a simple and standard protocol (like
"inspect") for editing ("edit"?) which would pull up the appropriate editor
depending on its content, class and context (i.e. command line/MVC/Morphic).

Subbu