<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 25, 2018, at 11:18 PM, Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" class="">marcel.taeumel@hpi.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div id="__MailbirdStyleContent" style="font-size: 12pt; font-family: calibri;" class=""><div class=""><span style="font-size: 12pt;" class="">One of the many nice things in Squeak is that you can evaluate code in any text field. </span></div></div></div></blockquote><div><br class=""></div><div>OK. It seems that PrintIt, DoIt, etc., are not still present in, say, a TextMorph dragged from Supplies, after loading my changeset. Hmm.</div><br class=""><blockquote type="cite" class=""><div class=""><div id="__MailbirdStyleContent" style="font-size: 12pt; font-family: calibri;" class=""><div class=""><span style="font-size: 12pt;" class="">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. :-)</span></div></div></div></blockquote><div><br class=""></div><div>Yes. :D</div><div><br class=""></div><div>As H. Hirzel suggested earlier in this thread, I wonder if the fact TextMorph is using SmalltalkEditor is actually a mistake from history. </div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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). </div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div id="__MailbirdStyleContent" style="font-size: 12pt; font-family: calibri;" class=""><div class="">Anyway, we might want to have "TextEditor", "StructuredEditor", and "SmalltalkEditor” ?</div></div></div></blockquote><div><br class=""></div><div>Yes, this sounds good to me too. I do fear the line might be quite blurred between StructuredEditor and SmalltalkEditor, but hopefully not.</div><br class=""><blockquote type="cite" class=""><div id="__MailbirdStyleContent" style="font-size: 12pt; font-family: calibri;" class=""><div class=""><span style="font-size: 12pt;" class="">Yes, the use of TextMorphForEditView is not necessarily an indication for a programming tool.</span></div></div></blockquote><div><br class=""></div><span class="">Yet, I did seem to find that TextMorphForEditView is mostly used in browsers, workspaces, and other ToolBuilder(?)-related windows. So, actually, </span>TextMorphForEditView seemed to be the most code-editing-specialized text morph. I wonder if there are places this is not the case.<span class=""><br class=""></span><span class=""><br class=""></span><span class=""><br class=""></span><blockquote type="cite" class=""><div class=""><div id="__MailbirdStyleContent" style="font-size: 12pt; font-family: calibri;" class=""><div class=""><br class=""></div><div class="">Hmmm…</div></div></div></blockquote><div><br class=""></div><div>Hmmm indeed!</div><div><br class=""></div><div>Thanks,</div><div>Tim</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div id="__MailbirdStyleContent" style="font-size: 12pt; font-family: calibri;" class=""><div class=""><br class=""></div><div class="">Best,</div><div class="">Marcel</div><div class="mb_sig"></div>
<blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px"><p style="color: #AAAAAA; margin-top: 10px;" class="">Am 25.03.2018 08:33:14 schrieb Tm Jhnsn <<a href="mailto:digit@sonic.net" class="">digit@sonic.net</a>>:</p>Hi Marcel,<br class=""><br class="">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.<br class=""><br class="">Thanks,<br class="">Tim<br class=""><br class="">On Mar 24, 2018, at 11:12 PM, Taeumel, Marcel wrote:<br class=""><br class="">> Hi, there.<br class="">> <br class="">> 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.<br class="">> <br class="">> Please, do not move these things down to SmalltalkEditor.<br class="">> <br class="">> Yet, we could think about separate preferences for Smalltalk editors and other editors.<br class="">> <br class="">> Best,<br class="">> Marcel<br class="">> <br class="">>> Am 24.03.2018 um 21:18 schrieb H. Hirzel <hannes.hirzel@gmail.com class="">:<br class="">>> <br class="">>> Hi Tim<br class="">>> <br class="">>> Thank you for looking into this issue and for the insightful analysis<br class="">>> <br class="">>> In my Squeak6.0alpha update: #17330 image I have<br class="">>> <br class="">>> TextMorph defaultEditorClass<br class="">>> <br class="">>> answering<br class="">>> <br class="">>> SmalltalkEditor<br class="">>> <br class="">>> <br class="">>> <br class="">>> I wonder how this got set<br class="">>> <br class="">>> <br class="">>> TextMorph defaultEditorClass: aTextEditorClass<br class="">>> "Sets the default editor class for TextMorph"<br class="">>> "<br class="">>> <br class="">>> has no senders.<br class="">>> <br class="">>> <br class="">>> <br class="">>> And BTW the comment in<br class="">>> <br class="">>> TextMorph defaultEditorClass: aTextEditorClass<br class="">>> <br class="">>> needs to be updated marking 'TextMorphEditor' as deprecated.<br class="">>> <br class="">>> <br class="">>> I wonder if it is just a mistake that the class variable<br class="">>> DefaultEditorClass in TextMorph got set wrongly?<br class="">>> <br class="">>> <br class="">>> Regards<br class="">>> Hannes<br class="">>> <br class="">>> <br class="">>>> On 3/24/18, Tim Johnson <digit@sonic.net class=""> wrote:<br class="">>>> Hi all,<br class="">>>> <br class="">>>> I went on a journey this morning which could have been quixotic, but I<br class="">>>> believe I actually found and slayed a small windmill.<br class="">>>> <br class="">>>> I was a bit annoyed by how autoEnclose (and by extension autoIndent)<br class="">>>> were in effect for even the most basic of TextMorphs, e.g. those dragged<br class="">>>> out of the Supplies flap. I was also kind of disappointed that turning<br class="">>>> on/off the auto-enclose preference affected all text morphs, even those<br class="">>>> not specifically designated for Smalltalk code editing. I was<br class="">>>> emboldened when I saw the class comment for TextEditor: "[I] have no<br class="">>>> specific facilities for editing Smalltalk code. Those are found in<br class="">>>> SmalltalkEditor."<br class="">>>> <br class="">>>> I found myself able to address this by making a few changes:<br class="">>>> <br class="">>>> * moving autoEnclose and autoIndent functionality out of TextEditor and<br class="">>>> into SmalltalkEditor<br class="">>>> <br class="">>>> * changing the default editor class for TextMorph to TextEditor<br class="">>>> <br class="">>>> * specifying that the #editorClass for TextMorphForEditView should be a<br class="">>>> SmalltalkEditor<br class="">>>> <br class="">>>> * changing PreferenceWizard to recognize these preferences have a new<br class="">>>> home<br class="">>>> <br class="">>>> I'm attaching a changeset to this email and not uploading an .mcz to<br class="">>>> inbox (sorry). This is because I don't know how to represent changes<br class="">>>> across many projects in Monticello, and I sort of consider this a<br class="">>>> proof-of-concept rather than something I think warrants immediate<br class="">>>> inclusion in the image.<br class="">>>> <br class="">>>> Please do let me know what you think about this idea.<br class="">>>> <br class="">>>> I also fear my implementation of<br class="">>>> SmalltalkEditor>>#dispatchOnKeyboardEvent: might be lacking.<br class="">>>> <br class="">>>> Thanks,<br class="">>>> Tim<br class="">>>> <br class="">>>> ps - I think a next step of moving Smalltalk editing support into<br class="">>>> SmalltalkEditor might be to move the call to<br class="">>>> ToolSet>>#codeCompletionAround:textMorph:keyStroke: out of<br class="">>>> TextMorph>>#keyStroke: and into its subclass, in<br class="">>>> TextMorphForEditView>>#keyStroke:. I didn't complete that move and did<br class="">>>> not quite figure out how the subclass version of that method works.<br class="">>> <br class="">> <br class="">> <br class=""><br class=""><br class=""></digit@sonic.net></hannes.hirzel@gmail.com>
</blockquote></div><br class=""></div></blockquote></div><br class=""></body></html>