Hi, there.
Both autoIndent and autoEnclose are not quite Smalltalk-specific. Take a look at other text editors out there like Sublime or Atom. Keeping the indent or adding the second character of an enclosing pair is quite generic.
Please, do not move these things down to SmalltalkEditor.
Yet, we could think about separate preferences for Smalltalk editors and other editors.
Best, Marcel
Am 24.03.2018 um 21:18 schrieb H. Hirzel hannes.hirzel@gmail.com:
Hi Tim
Thank you for looking into this issue and for the insightful analysis
In my Squeak6.0alpha update: #17330 image I have
TextMorph defaultEditorClassanswering
SmalltalkEditorI 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: aTextEditorClassneeds 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?
Regards Hannes
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.