From the perspective of a casual, though committed, Squeak user, I find value in this approach. It is confusing to identify an object which looks promising to use in an application that is overloaded with use-case specific baggage. #PluggableTextMorph is one example, it seems to be biased towards code composition. I would like to see high-level objects contain the essentials for its purpose with specialized sub-classes providing more application specific additions.

I don't know how this scenario plays out in ObjectOriented architecture, but I think "just enough, but not more" is good guidance for a base class.

As far as taking questionable behavior options to #Preferences, that realm seems to be pretty complicated already.

That being said, I have no objections to any reasonable modifications anyone is willing to invest time and effort in providing ;-) I am providing this feedback because I have been working to develop my skill at writing simple, typical, form (in the fill out the form business sense) style applications, texteditor behavior is something with which I have been wrestling.

- jrm

On Sat, Mar 24, 2018 at 7:04 AM, Tim Johnson <digit@sonic.net> wrote:
Hi all,

I went on a journey this morning which could have been quixotic, but I believe I actually found and slayed a small windmill.

I was a bit annoyed by how autoEnclose (and by extension autoIndent) were in effect for even the most basic of TextMorphs, e.g. those dragged out of the Supplies flap. I was also kind of disappointed that turning on/off the auto-enclose preference affected all text morphs, even those not specifically designated for Smalltalk code editing.  I was emboldened when I saw the class comment for TextEditor: "[I] have no specific facilities for editing Smalltalk code. Those are found in SmalltalkEditor."

I found myself able to address this by making a few changes:

* moving autoEnclose and autoIndent functionality out of TextEditor and into SmalltalkEditor

* changing the default editor class for TextMorph to TextEditor

* specifying that the #editorClass for TextMorphForEditView should be a SmalltalkEditor

* changing PreferenceWizard to recognize these preferences have a new home

I'm attaching a changeset to this email and not uploading an .mcz to inbox (sorry).  This is because I don't know how to represent changes across many projects in Monticello, and I sort of consider this a proof-of-concept rather than something I think warrants immediate inclusion in the image.

Please do let me know what you think about this idea.

I also fear my implementation of SmalltalkEditor>>#dispatchOnKeyboardEvent: might be lacking.

Thanks,
Tim

ps - I think a next step of moving Smalltalk editing support into SmalltalkEditor might be to move the call to ToolSet>>#codeCompletionAround:textMorph:keyStroke: out of TextMorph>>#keyStroke: and into its subclass, in TextMorphForEditView>>#keyStroke:.  I didn't complete that move and did not quite figure out how the subclass version of that method works.