<div id="__MailbirdStyleContent" style="font-size: 12pt;font-family: calibri;color: #000000">
Yeah, "structured information" is not always code. :-)<div><br></div><div>One of the many nice things in Squeak is that you can evaluate code in any text field. 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. :-) Anyway, we might want to have "TextEditor", "StructuredEditor", and "SmalltalkEditor" ?</div><div><br></div><div>Yes, the use of TextMorphForEditView is not necessarily an indication for a programming tool.</div><div><br></div><div>Hmmm...</div><div><br></div><div>Best,</div><div>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;">Am 25.03.2018 08:33:14 schrieb Tm Jhnsn <digit@sonic.net>:</p>Hi Marcel,<br><br>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><br>Thanks,<br>Tim<br><br>On Mar 24, 2018, at 11:12 PM, Taeumel, Marcel wrote:<br><br>> Hi, there.<br>> <br>> 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>> <br>> Please, do not move these things down to SmalltalkEditor.<br>> <br>> Yet, we could think about separate preferences for Smalltalk editors and other editors.<br>> <br>> Best,<br>> Marcel<br>> <br>>> Am 24.03.2018 um 21:18 schrieb H. Hirzel <hannes.hirzel@gmail.com>:<br>>> <br>>> Hi Tim<br>>> <br>>> Thank you for looking into this issue and for the insightful analysis<br>>> <br>>> In my Squeak6.0alpha update: #17330 image I have<br>>> <br>>> TextMorph defaultEditorClass<br>>> <br>>> answering<br>>> <br>>> SmalltalkEditor<br>>> <br>>> <br>>> <br>>> I wonder how this got set<br>>> <br>>> <br>>> TextMorph defaultEditorClass: aTextEditorClass<br>>> "Sets the default editor class for TextMorph"<br>>> "<br>>> <br>>> has no senders.<br>>> <br>>> <br>>> <br>>> And BTW the comment in<br>>> <br>>> TextMorph defaultEditorClass: aTextEditorClass<br>>> <br>>> needs to be updated marking 'TextMorphEditor' as deprecated.<br>>> <br>>> <br>>> I wonder if it is just a mistake that the class variable<br>>> DefaultEditorClass in TextMorph got set wrongly?<br>>> <br>>> <br>>> Regards<br>>> Hannes<br>>> <br>>> <br>>>> On 3/24/18, Tim Johnson <digit@sonic.net> wrote:<br>>>> Hi all,<br>>>> <br>>>> I went on a journey this morning which could have been quixotic, but I<br>>>> believe I actually found and slayed a small windmill.<br>>>> <br>>>> I was a bit annoyed by how autoEnclose (and by extension autoIndent)<br>>>> were in effect for even the most basic of TextMorphs, e.g. those dragged<br>>>> out of the Supplies flap. I was also kind of disappointed that turning<br>>>> on/off the auto-enclose preference affected all text morphs, even those<br>>>> not specifically designated for Smalltalk code editing. I was<br>>>> emboldened when I saw the class comment for TextEditor: "[I] have no<br>>>> specific facilities for editing Smalltalk code. Those are found in<br>>>> 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<br>>>> into SmalltalkEditor<br>>>> <br>>>> * changing the default editor class for TextMorph to TextEditor<br>>>> <br>>>> * specifying that the #editorClass for TextMorphForEditView should be a<br>>>> SmalltalkEditor<br>>>> <br>>>> * changing PreferenceWizard to recognize these preferences have a new<br>>>> home<br>>>> <br>>>> I'm attaching a changeset to this email and not uploading an .mcz to<br>>>> inbox (sorry). This is because I don't know how to represent changes<br>>>> across many projects in Monticello, and I sort of consider this a<br>>>> proof-of-concept rather than something I think warrants immediate<br>>>> 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<br>>>> SmalltalkEditor>>#dispatchOnKeyboardEvent: might be lacking.<br>>>> <br>>>> Thanks,<br>>>> Tim<br>>>> <br>>>> ps - I think a next step of moving Smalltalk editing support into<br>>>> SmalltalkEditor might be to move the call to<br>>>> ToolSet>>#codeCompletionAround:textMorph:keyStroke: out of<br>>>> TextMorph>>#keyStroke: and into its subclass, in<br>>>> TextMorphForEditView>>#keyStroke:. I didn't complete that move and did<br>>>> not quite figure out how the subclass version of that method works.<br>>> <br>> <br>> <br><br><br></digit@sonic.net></hannes.hirzel@gmail.com>
</blockquote></div>