[squeak-dev] Proof-of-concept: moving Smalltalk code editing support into SmalltalkEditor

Marcel Taeumel marcel.taeumel at hpi.de
Mon Mar 26 06:18:09 UTC 2018


Yeah, "structured information" is not always code. :-)

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" ?

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

Hmmm...

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/f34d25e9/attachment.html>


More information about the Squeak-dev mailing list