[squeak-dev] Proof-of-concept: moving Smalltalk code editing support into SmalltalkEditor

H. Hirzel hannes.hirzel at gmail.com
Sat Mar 24 20:18:24 UTC 2018

Hi Tim

Thank you for looking into this issue and for the insightful analysis

In my Squeak6.0alpha update: #17330 image I have

      TextMorph defaultEditorClass



I wonder how this got set

    TextMorph defaultEditorClass: aTextEditorClass
    	"Sets the default editor class for TextMorph"

has no senders.

And BTW the comment in

     TextMorph defaultEditorClass: aTextEditorClass

needs to be updated marking 'TextMorphEditor' as deprecated.

I wonder if it is just a mistake that the class variable
DefaultEditorClass in TextMorph got set wrongly?


On 3/24/18, Tim Johnson <digit at 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.

More information about the Squeak-dev mailing list