>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.

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.

As far as taking questionable behavior options to #Preferences, that realm
seems to be pretty complicated already.

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.

- jrm

On Sat, Mar 24, 2018 at 7:04 AM, 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.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180325/94ddb7e1/attachment.html>