> On Mar 25, 2018, at 11:18 PM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> 
> One of the many nice things in Squeak is that you can evaluate code in any text field.

OK.  It seems that PrintIt, DoIt, etc., are not still present in, say, a TextMorph dragged from Supplies, after loading my changeset.  Hmm.

> A little compromise could be to remove "DefaultEditorClass" and just use #editorClass to return "TextEditor" in "TextMorph" and "SmalltalkEditor" in "TextMorphForEditView" ... which you might have been already suggested in your previous mails. :-)

Yes.  :D

As H. Hirzel suggested earlier in this thread, I wonder if the fact TextMorph is using SmalltalkEditor is actually a mistake from history.  

It seems SmalltalkEditor is not currently a very fleshed-out class.  So I did mean to demonstrate that some amount of functionality will probably need to be yanked out of TextEditor and into SmalltalkEditor or a StructuredEditor / CodeEditor.  This seems to be in the spirit of jrm’s post on in this thread … and is also what I intended to partially demonstrate in my changeset.

Efforts made here may also aid what Tim Rowledge pointed out (if I’m reading correctly):  that the text-styling capabilities and text-editing shortcuts are currently kind of difficult to comprehend.  For example, I’ve been trying to come to terms with in which cases Cmd-0 through Cmd-5 will have any of their various (overloaded?) effects.  Sometimes, they make text disappear.  But sometimes, they do indeed change font qualities.  I think it may depend on whether text styles have been applied by one method or another.  Still digging into that one:  I was recently hunting down a DNU from hitting Cmd-9 only while inside a purple-colored styled text (a string).  

> Anyway, we might want to have "TextEditor", "StructuredEditor", and "SmalltalkEditor” ?

Yes, this sounds good to me too.  I do fear the line might be quite blurred between StructuredEditor and SmalltalkEditor, but hopefully not.

> Yes, the use of TextMorphForEditView is not necessarily an indication for a programming tool.

Yet, I did seem to find that TextMorphForEditView is mostly used in browsers, workspaces, and other ToolBuilder(?)-related windows.  So, actually, TextMorphForEditView seemed to be the most code-editing-specialized text morph.  I wonder if there are places this is not the case.


> 
> Hmmm…

Hmmm indeed!

Thanks,
Tim


> 
> Best,
> Marcel
>> Am 25.03.2018 08:33:14 schrieb Tm Jhnsn <digit at sonic.net>:
>> 
>> Hi Marcel,
>> 
>> I certainly agree with you that this is a useful feature which some people prefer/expect in code editors. But here I am also thinking about "text" "editors" like Microsoft Word, OpenOffice, Notepad, TextEdit, etc. I suppose I am bringing about a philosophical question.
>> 
>> Thanks,
>> Tim
>> 
>> On Mar 24, 2018, at 11:12 PM, Taeumel, Marcel wrote:
>> 
>> > 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 :
>> >> 
>> >> Hi Tim
>> >> 
>> >> Thank you for looking into this issue and for the insightful analysis
>> >> 
>> >> 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.
>> >> 
>> >> 
>> >> 
>> >> 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?
>> >> 
>> >> 
>> >> Regards
>> >> Hannes
>> >> 
>> >> 
>> >>> On 3/24/18, Tim Johnson 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/20180326/0c41c0f5/attachment.html>