I didn't look at your changeset to know if it affects any of the defaults from an image-perspective. If your proposal is to make TextMorph cleaner without affecting the standard, out-of-the-box Smalltalk user-experience when someone downloads Squeak, then I think that could be a good thing. On Wed, Aug 29, 2018 at 4:10 PM Chris Muller asqueaker@gmail.com wrote:
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.