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

Tm Jhnsn digit at sonic.net
Sun Mar 25 06:33:04 UTC 2018


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 <hannes.hirzel at gmail.com>:
>> 
>> 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 <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.
>> 
> 
> 



More information about the Squeak-dev mailing list