Andrew Tween wrote:
> When installled, Shout registers PluggableShoutMorph as the default
> MorphicTextEditor under AppRegistry.

Sorry, I wasn't aware of that. In this case, this whole discussion is 
fairly irrelevant (and I get Lex's point even less) since you aren't 
even modifying the basic text editor but rather plugging into the 
appropriate interface for it. No overrides needed, just a plain old API 
being used. Nevermind.

Cheers,
   - Andreas

> PluggableShoutMorph has a 'styler' instance variable which holds an
> SHTextStylerST80. When the text changes, the styler is instructed to parse, and
> style, the Text.
> 
> Now, if the styler instance variable were in PluggableTextMorph (or higher), any
> alternative syntax highlighter could be plugged in. It would just need to
> implement the public interface of SHTextStylerST80...
>     #style: <Text>
>     #styleInBackgroundProcess:<Text>
>     #format: <Text>
>     #unstyledTextFrom: <Text>
> .. and PluggableTextMorph would need to include the hacks (!?) from
> PluggableShoutMorph to update its contents from the re-styled Text.
> 
>> Coincidentally, this is *precisely* what I referred to earlier
>> wrt. explicit vs. implicit interactions. As it stands, loading an
>> alternative syntax highlighter will (almost necessarily) clash with
>> shout;
> 
> Not if it registers itself as the default (or an alternative) MorphicTextEditor.
> Or, uses Shout, but implements an alternative to SHTextStylerST80.
> 
> (Incidently, I think it would be good to have a MorphicCodeEditor in addition to
> MorphicTextEditor).
> 
>> with that interface both modules could use the same ground rules,
>> could be loaded side by side and could be activated depending on the
>> context you need them in.
> 
> Yes, that would be good.
> 
> Cheers,
> Andy
> 
> 
>