Hi Tim,

> I was a bit annoyed by how autoEnclose (and by extension autoIndent)
> were in effect for even the most basic of TextMorphs,

autoEnclose is not Smalltalk-specific.  In all languages, including
plain English, when you use an opening parenthesis, 9 times out of 10,
there's gonna be a closing one, so autoEnclose is convenient pretty
much everywhere.  The exceptions are a tiny minority.  Nevertheless,
these are independently adjustable preferences which you can turn off
if it doesn't suit you and they won't bother you even in
SmalltalkEditors.

> 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

-1.   I need autoEnclose for all my writing, not just Smalltalk code.

> * changing the default editor class for TextMorph to TextEditor

Applications which want to prevent users from being able to access
Smalltalk can and should be able to do that, however, just as
spreadsheet cells accept formulas, in a Smalltalk environment the
default should be the one that accepts Smalltalk expressions.  With
Syntax Highlighting off, it's virtually the same as a basic
text-editor for anyone who doesn't know Smalltalk-ability is there.

Best,
  Chris

> * 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.
>