<div dir="ltr">From the perspective of a casual, though committed, Squeak user, I find value in this approach. It is confusing to identify an object which looks promising to use in an application that is overloaded with use-case specific baggage. #PluggableTextMorph is one example, it seems to be biased towards code composition. I would like to see high-level objects contain the essentials for its purpose with specialized sub-classes providing more application specific additions.<div><br></div><div>I don't know how this scenario plays out in ObjectOriented architecture, but I think "just enough, but not more" is good guidance for a base class.</div><div><br></div><div>As far as taking questionable behavior options to #Preferences, that realm seems to be pretty complicated already.</div><div><br></div><div>That being said, I have no objections to any reasonable modifications anyone is willing to invest time and effort in providing ;-) I am providing this feedback because I have been working to develop my skill at writing simple, typical, form (in the fill out the form business sense) style applications, texteditor behavior is something with which I have been wrestling.</div><div><br></div><div>- jrm</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 24, 2018 at 7:04 AM, Tim Johnson <span dir="ltr"><<a href="mailto:digit@sonic.net" target="_blank">digit@sonic.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I went on a journey this morning which could have been quixotic, but I believe I actually found and slayed a small windmill.<br>
<br>
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."<br>
<br>
I found myself able to address this by making a few changes:<br>
<br>
* moving autoEnclose and autoIndent functionality out of TextEditor and into SmalltalkEditor<br>
<br>
* changing the default editor class for TextMorph to TextEditor<br>
<br>
* specifying that the #editorClass for TextMorphForEditView should be a SmalltalkEditor<br>
<br>
* changing PreferenceWizard to recognize these preferences have a new home<br>
<br>
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.<br>
<br>
Please do let me know what you think about this idea.<br>
<br>
I also fear my implementation of SmalltalkEditor>>#dispatchOnKe<wbr>yboardEvent: might be lacking.<br>
<br>
Thanks,<br>
Tim<br>
<br>
ps - I think a next step of moving Smalltalk editing support into SmalltalkEditor might be to move the call to ToolSet>>#codeCompletionAround<wbr>:textMorph:keyStroke: out of TextMorph>>#keyStroke: and into its subclass, in TextMorphForEditView>>#keyStro<wbr>ke:.  I didn't complete that move and did not quite figure out how the subclass version of that method works.<br>
<br><br>
<br></blockquote></div><br></div>