Hi Hannes,
On Mar 24, 2018, at 1:18 PM, H. Hirzel hannes.hirzel@gmail.com wrote:
Hi Tim
Thank you for looking into this issue and for the insightful analysis
My pleasure! Thank you for your thoughtful response.
In my Squeak6.0alpha update: #17330 image I have
TextMorph defaultEditorClass
answering
SmalltalkEditor
I wonder how this got set
TextMorph defaultEditorClass: aTextEditorClass "Sets the default editor class for TextMorph" "
has no senders.
You may want to look in TextMorph class>>#initialize — you will find:
DefaultEditorClass := TextEditor. or DefaultEditorClass := SmalltalkEditor.
…of course, after changing this, (as is done in a postamble script in my changeset), TextMorph class must be re-initialized.
Does that explain the situation?
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?
Yes, me too.
Thanks, Tim
On 3/24/18, 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.