Smalltalk › Squeak › Squeak - Dev

Proof-of-concept: moving Smalltalk code editing support into SmalltalkEditor

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

20 messages Options

Tim Johnson-2

Proof-of-concept: moving Smalltalk code editing support into SmalltalkEditor

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.

MoveUpAutoIndentAndEnclose.1.cs (16K) Download Attachment

Hannes Hirzel

Re: Proof-of-concept: moving Smalltalk code editing support into SmalltalkEditor

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 <[hidden email]> 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.
>

marcel.taeumel

Re: Proof-of-concept: moving Smalltalk code editing support into SmalltalkEditor

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 <[hidden email]>:
>
> 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 <[hidden email]> 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.
>

Tim Johnson-2

Re: Proof-of-concept: moving Smalltalk code editing support into SmalltalkEditor

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 <[hidden email]>:
>>
>> 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 <[hidden email]> 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.
>>
>
>

timrowledge

Re: Proof-of-concept: moving Smalltalk code editing support into SmalltalkEditor

In reply to this post by marcel.taeumel

> On 24-03-2018, at 11:12 PM, Taeumel, Marcel <[hidden email]> wrote:
>
> Yet, we could think about separate preferences for Smalltalk editors and other editors.

Maybe even per-editor instance preferences. Inherit the global as a default but allow changing at need. Need a UI to make it useful. Actually we really need some big improvements to the prefs/settings/style/font/colour stuff for editors anyway.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"Bother" said Pooh, and deleted his message base

jrm

Re: Proof-of-concept: moving Smalltalk code editing support into SmalltalkEditor

In reply to this post by Tim Johnson-2

From the perspective of a casual, though committed, Squeak user, I find value in this approach. It is confusing to identify an object which looks promising to use in an application that is overloaded with use-case specific baggage. #PluggableTextMorph is one example, it seems to be biased towards code composition. I would like to see high-level objects contain the essentials for its purpose with specialized sub-classes providing more application specific additions.

I don't know how this scenario plays out in ObjectOriented architecture, but I think "just enough, but not more" is good guidance for a base class.

As far as taking questionable behavior options to #Preferences, that realm seems to be pretty complicated already.

That being said, I have no objections to any reasonable modifications anyone is willing to invest time and effort in providing ;-) I am providing this feedback because I have been working to develop my skill at writing simple, typical, form (in the fill out the form business sense) style applications, texteditor behavior is something with which I have been wrestling.

- jrm

On Sat, Mar 24, 2018 at 7:04 AM, Tim Johnson <[hidden email]> 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.

Chris Muller-3

Re: Proof-of-concept: moving Smalltalk code editing support into SmalltalkEditor

In reply to this post by timrowledge

> Maybe even per-editor instance preferences. Inherit the global as a default but allow changing at need. Need a UI to make it useful. Actually we really need some big improvements to the prefs/settings/style/font/colour stuff for editors anyway.

UserInterfaceTheme in the image does that. We did it in summer of
2016, the color themes work pretty well ever since.

marcel.taeumel

Re: Proof-of-concept: moving Smalltalk code editing support into SmalltalkEditor

Well, we usually ask the current UI theme about properties during widget initialization. Thus, you can override those props after the widget was created. Only if you then choose another UI theme, those props will be reset and overwritten because we did not yet implement a generic "wasOverridden" flag to avoid updates in those cases on a per widget-instance basis.

For more information, browse the implementors of #setDefaultParameters and also its senders, which are #initialize and #applyUserInterfaceTheme for (pluggable) widgets.

Best,

Marcel

Am 26.03.2018 05:53:05 schrieb Chris Muller <[hidden email]>:
> Maybe even per-editor instance preferences. Inherit the global as a default but allow changing at need. Need a UI to make it useful. Actually we really need some big improvements to the prefs/settings/style/font/colour stuff for editors anyway.

UserInterfaceTheme in the image does that. We did it in summer of
2016, the color themes work pretty well ever since.

marcel.taeumel

Re: Proof-of-concept: moving Smalltalk code editing support into SmalltalkEditor

In reply to this post by Tim Johnson-2

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 <[hidden email]>:
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.
>>
>
>

Tim Johnson-2

Re: Proof-of-concept: moving Smalltalk code editing support into SmalltalkEditor

In reply to this post by Hannes Hirzel

Hi Hannes,

> On Mar 24, 2018, at 1:18 PM, H. Hirzel <[hidden email]> wrote:
>
> Hi Tim
>
> Thank you for looking into this issue and for the insightful analysis

My pleasure! Thank you for your thoughtful response.

>
> 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.

You may want to look in TextMorph class>>#initialize — you will find:

DefaultEditorClass := TextEditor.
or
DefaultEditorClass := SmalltalkEditor.

…of course, after changing this, (as is done in a postamble script in my changeset), TextMorph class must be re-initialized.

Does that explain the situation?

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

Yes, me too.

Thanks,
Tim

>
>
> On 3/24/18, Tim Johnson <[hidden email]> 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.
>>
>
>

Tim Johnson-2

Re: Proof-of-concept: moving Smalltalk code editing support into SmalltalkEditor

In reply to this post by marcel.taeumel

On Mar 25, 2018, at 11:18 PM, Marcel Taeumel <[hidden email]> 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 <[hidden email]>:
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.
>>
>
>

timrowledge

Re: Proof-of-concept: moving Smalltalk code editing support into SmalltalkEditor

In reply to this post by Chris Muller-3

> On 25-03-2018, at 8:52 PM, Chris Muller <[hidden email]> wrote:
>
>> Maybe even per-editor instance preferences. Inherit the global as a default but allow changing at need. Need a UI to make it useful. Actually we really need some big improvements to the prefs/settings/style/font/colour stuff for editors anyway.
>
> UserInterfaceTheme in the image does that. We did it in summer of
> 2016, the color themes work pretty well ever since.

I was thinking more of the UI for changing text styles/font/colours within editors etc. Marcel's answer about having properties within the themes that could cover these sounds interesting.

I've just noticed an extra bit of complication when thinking about this wrt Shout colouring - just try cmd-7 with some selected text in a code view! Even in a comment...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Diagnostics are the programs that run when nothing else will.

marcel.taeumel

Re: Proof-of-concept: moving Smalltalk code editing support into SmalltalkEditor

Shout wants to be the only mechanism that governs text attributes in a (pluggable) text morph. It does not keep track of its own additions or anything that has been there before. You cannot even combine two different kinds of "Shout stylers" if you would want to. Thus, any manual changes to text attributes will be discarded once Shout decides to re-style the text contents again. That is why CMD-7 does not work as expected if a text morph has a styler and hence Shout styling enabled.

We decided to put all Shout-styling properties into the UI themes because code styling is closely related to all other visual properties in the system. For example, the code as to look different in "Solarized" than it does in "Monokai" or "Default Squeak":

If you want to write a tool or application that DOES NOT comply with UI themes, you might encounter several barriers at this moment. However, there is #canApplyUserInterfaceTheme implemented in Morph to start thinking about this challenge. You can set the property #noUserInterfaceTheme to avoid UI-theme application. This suggests a bigger refactoring I should approach. All calls to #setDefaultParameters might need to happen through #applyUserInterfaceTheme, which me might want to guard for Morphs, for example. Let me think about that.

Anyway: Managing side effects and state in an image-based object system remains challenging. :-)

Best,

Marcel

Am 26.03.2018 20:22:36 schrieb tim Rowledge <[hidden email]>:

> On 25-03-2018, at 8:52 PM, Chris Muller wrote:
>
>> Maybe even per-editor instance preferences. Inherit the global as a default but allow changing at need. Need a UI to make it useful. Actually we really need some big improvements to the prefs/settings/style/font/colour stuff for editors anyway.
>
> UserInterfaceTheme in the image does that. We did it in summer of
> 2016, the color themes work pretty well ever since.

I was thinking more of the UI for changing text styles/font/colours within editors etc. Marcel's answer about having properties within the themes that could cover these sounds interesting.

I've just noticed an extra bit of complication when thinking about this wrt Shout colouring - just try cmd-7 with some selected text in a code view! Even in a comment...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Diagnostics are the programs that run when nothing else will.

Hannes Hirzel

Re: Proof-of-concept: moving Smalltalk code editing support into SmalltalkEditor

Hello

The issue of this thread was continued
in http://forum.world.st/The-Inbox-Tools-LM-827-mcz-tp5083799p5083857.html

So let's discuss this further here...

Yes, a group of Squeak pages outlining the issues would be great!

HH

----------------------------------
by Tim Johnson

Aug 29, 2018; 4:46pm Tim Johnson-2 Tim Johnson-2
Hi,

I have seen all the follow-up on this thread, so I understand that the
preference was found and this commit was retracted. However, I just
want to register myself as someone who uses Workspaces for more than
just code. I keep TODOs there, notes, and snippets of external data
formats.

I did dig into making a more plaintext-only or styled-text-only
editing space in Squeak a few months back and posted a long
description of my experiences. The main takeaway (without specifics,
meaning I will probably mis-state in this email) was that it seems
there has been some … cross-pollination (?) … between general-purpose
text editing classes and code-oriented text editing classes over
Squeak’s lifetime. To me, it looked like a number of code-oriented
extensions were added to non-code-specific classes at one point, and
this seemed to expose different philosophies and open deep questions
on this mailing list. :)

Anyway, I fear I may be hijacking this thread a bit. Maybe I should
dig up that old message I wrote and turn it into a Swiki page.

Thanks,
Tim
-------------------------

On 3/27/18, Marcel Taeumel <[hidden email]> wrote:

> Shout wants to be the only mechanism that governs text attributes in a
> (pluggable) text morph. It does not keep track of its own additions or
> anything that has been there before. You cannot even combine two different
> kinds of "Shout stylers" if you would want to. Thus, any manual changes to
> text attributes will be discarded once Shout decides to re-style the text
> contents again. That is why CMD-7 does not work as expected if a text morph
> has a styler and hence Shout styling enabled.
>
> We decided to put all Shout-styling properties into the UI themes because
> code styling is closely related to all other visual properties in the
> system. For example, the code as to look different in "Solarized" than it
> does in "Monokai" or "Default Squeak":
>
>
> If you want to write a tool or application that DOES NOT comply with UI
> themes, you might encounter several barriers at this moment. However, there
> is #canApplyUserInterfaceTheme implemented in Morph to start thinking about
> this challenge. You can set the property #noUserInterfaceTheme to avoid
> UI-theme application. This suggests a bigger refactoring I should approach.
> All calls to #setDefaultParameters might need to happen through
> #applyUserInterfaceTheme, which me might want to guard for Morphs, for
> example. Let me think about that.
>
> Anyway: Managing side effects and state in an image-based object system
> remains challenging. :-)
>
> Best,
> Marcel
> Am 26.03.2018 20:22:36 schrieb tim Rowledge <[hidden email]>:
>
>
>> On 25-03-2018, at 8:52 PM, Chris Muller wrote:
>>
>>> Maybe even per-editor instance preferences. Inherit the global as a
>>> default but allow changing at need. Need a UI to make it useful. Actually
>>> we really need some big improvements to the
>>> prefs/settings/style/font/colour stuff for editors anyway.
>>
>> UserInterfaceTheme in the image does that. We did it in summer of
>> 2016, the color themes work pretty well ever since.
>
> I was thinking more of the UI for changing text styles/font/colours within
> editors etc. Marcel's answer about having properties within the themes that
> could cover these sounds interesting.
>
> I've just noticed an extra bit of complication when thinking about this wrt
> Shout colouring - just try cmd-7 with some selected text in a code view!
> Even in a comment...
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Diagnostics are the programs that run when nothing else will.
>
>
>
>

Chris Muller-3

Re: Proof-of-concept: moving Smalltalk code editing support into SmalltalkEditor

In reply to this post by Tim Johnson-2

Hi Tim,

> I was a bit annoyed by how autoEnclose (and by extension autoIndent)
> were in effect for even the most basic of TextMorphs,

autoEnclose is not Smalltalk-specific. In all languages, including
plain English, when you use an opening parenthesis, 9 times out of 10,
there's gonna be a closing one, so autoEnclose is convenient pretty
much everywhere. The exceptions are a tiny minority. Nevertheless,
these are independently adjustable preferences which you can turn off
if it doesn't suit you and they won't bother you even in
SmalltalkEditors.

> 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

-1. I need autoEnclose for all my writing, not just Smalltalk code.

> * changing the default editor class for TextMorph to TextEditor

Applications which want to prevent users from being able to access
Smalltalk can and should be able to do that, however, just as
spreadsheet cells accept formulas, in a Smalltalk environment the
default should be the one that accepts Smalltalk expressions. With
Syntax Highlighting off, it's virtually the same as a basic
text-editor for anyone who doesn't know Smalltalk-ability is there.

Best,
Chris

> * 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.
>

Chris Muller-3

Re: Proof-of-concept: moving Smalltalk code editing support into SmalltalkEditor

I didn't look at your changeset to know if it affects any of the
defaults from an image-perspective. If your proposal is to make
TextMorph cleaner without affecting the standard, out-of-the-box
Smalltalk user-experience when someone downloads Squeak, then I think
that could be a good thing.
On Wed, Aug 29, 2018 at 4:10 PM Chris Muller <[hidden email]> wrote:

>
> Hi Tim,
>
> > I was a bit annoyed by how autoEnclose (and by extension autoIndent)
> > were in effect for even the most basic of TextMorphs,
>
> autoEnclose is not Smalltalk-specific. In all languages, including
> plain English, when you use an opening parenthesis, 9 times out of 10,
> there's gonna be a closing one, so autoEnclose is convenient pretty
> much everywhere. The exceptions are a tiny minority. Nevertheless,
> these are independently adjustable preferences which you can turn off
> if it doesn't suit you and they won't bother you even in
> SmalltalkEditors.
>
> > 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
>
> -1. I need autoEnclose for all my writing, not just Smalltalk code.
>
> > * changing the default editor class for TextMorph to TextEditor
>
> Applications which want to prevent users from being able to access
> Smalltalk can and should be able to do that, however, just as
> spreadsheet cells accept formulas, in a Smalltalk environment the
> default should be the one that accepts Smalltalk expressions. With
> Syntax Highlighting off, it's virtually the same as a basic
> text-editor for anyone who doesn't know Smalltalk-ability is there.
>
> Best,
> Chris
>
> > * 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.
> >

Bob Arning-2

Re: Proof-of-concept: moving Smalltalk code editing support into SmalltalkEditor

In reply to this post by Chris Muller-3

It's funny how irritated I get with other non-Smalltalk editing systems that do not (seem to, anyway) allow me to get text enclosed or unenclosed easily. Just plain text.

On 8/29/18 5:10 PM, Chris Muller wrote:

I was a bit annoyed by how autoEnclose (and by extension autoIndent)
were in effect for even the most basic of TextMorphs,

autoEnclose is not Smalltalk-specific.  In all languages, including
plain English, when you use an opening parenthesis, 9 times out of 10,
there's gonna be a closing one, so autoEnclose is convenient pretty
much everywhere.  The exceptions are a tiny minority.  Nevertheless,
these are independently adjustable preferences which you can turn off
if it doesn't suit you and they won't bother you even in
SmalltalkEditors.

timrowledge

Re: Proof-of-concept: moving Smalltalk code editing support into SmalltalkEditor

auto-enclose is one of those things that relates to how one types and the present circumstances of work. I find it utterly infuriating; Chris finds it essential. Being able to select some text and enclose it with my choice of delimiter is essential to me - but having the automatic doubling of a delimiter whether I actually need it or not is just a bad match for my usage.

It's a similar thing with the code styling. I really don't like automagic styling as done by Shout a great deal (but it's much less annoying now that Cog runs on Pi, since a non-trivial part of the irritation was the way it really slowed down the old VMs). I might like it more if it were also doing some of the pretty-printing format regularisation BUT I really suspect that 'physically' moving your typing around as you go would be annoying. Also, I'd probably like it a bit more if the styling cues were a little more visible to aging eyes.

auto-indent actually seems to work ok for my usage but I imagine it might be something that could work with a styler to help keep formatting nice.

I fear editor choices is just one of those things that somehow gloms onto the same parts of the brain that religionism attacks.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
All new: The software is not compatible with previous versions.

Chris Muller-3

Re: Proof-of-concept: moving Smalltalk code editing support into SmalltalkEditor

> auto-enclose is one of those things that relates to how one types and the present circumstances of work. I find it utterly infuriating; Chris finds it essential. Being able to select some text and enclose it with my choice of delimiter is essential to me - but having the automatic doubling of a delimiter whether I actually need it or not is just a bad match for my usage.

It no longer "doubles" the closing parenthesis, so you can type
exactly the same (including the closing paren) and you'll get exactly
the same results -- just a single closing paren -- just as when its
off.

I understand it still may not suit you, but I just wanted to make sure
you knew that aspect was fixed a while back...

> It's a similar thing with the code styling. I really don't like automagic styling as done by Shout a great deal (but it's much less annoying now that Cog runs on Pi, since a non-trivial part of the irritation was the way it really slowed down the old VMs). I might like it more if it were also doing some of the pretty-printing format regularisation BUT I really suspect that 'physically' moving your typing around as you go would be annoying.

Indeed! When I change existing methods, I often type the new code up
against the left margin as fast as I can (no tabs and totally
unformatted) so I can easily _see_ which parts of the method I'm
changing. Then before saving, I'll just use [Command+Shift+S] to
format the whole method in one shot. I actually detest "autoIndent"
because it gets in the way of that and mostly just complexifies the
tabbing (sometimes you need [Tab], sometimes [Backspace], where's the
improvement?).

An alternative to this which may alleviate your performance concern
would be to add a preference something like, "Style Continuously",
which would do either all the time like now or only when you
pretty-print or save the method.

> Also, I'd probably like it a bit more if the styling cues were a little more visible to aging eyes.

Have you tried the Community Theme? A lot of UI design thought went
into it. If you don't like it, its easy to customize a theme for your
eyes.

> auto-indent actually seems to work ok for my usage but I imagine it might be something that could work with a styler to help keep formatting nice.

What I want is to be able to use Command+Shift+S on only the
*selected* code instead of the whole method. It seemed like a simple
change (changeset attached) but unfortunately the compiler only
compiles whole chunks of code that include, for example, all the
variable definitions too, not just the partials code that was
selected.

TextEditor-prettyPrint.st (1K) Download Attachment

Hannes Hirzel

Re: Proof-of-concept: moving Smalltalk code editing support into SmalltalkEditor

Referring to the main topic of this thread: maybe we need a fourth
editor class: CodeEditor

Editor : http://wiki.squeak.org/squeak/2733

TextEditor : http://wiki.squeak.org/squeak/2729

CodeEditor : ?

SmalltalkEditor: http://wiki.squeak.org/squeak/2734

On 8/30/18, Chris Muller <[hidden email]> wrote:

>> auto-enclose is one of those things that relates to how one types and the
>> present circumstances of work. I find it utterly infuriating; Chris finds
>> it essential. Being able to select some text and enclose it with my choice
>> of delimiter is essential to me - but having the automatic doubling of a
>> delimiter whether I actually need it or not is just a bad match for my
>> usage.
>
> It no longer "doubles" the closing parenthesis, so you can type
> exactly the same (including the closing paren) and you'll get exactly
> the same results -- just a single closing paren -- just as when its
> off.
>
> I understand it still may not suit you, but I just wanted to make sure
> you knew that aspect was fixed a while back...
>
>> It's a similar thing with the code styling. I really don't like automagic
>> styling as done by Shout a great deal (but it's much less annoying now
>> that Cog runs on Pi, since a non-trivial part of the irritation was the
>> way it really slowed down the old VMs). I might like it more if it were
>> also doing some of the pretty-printing format regularisation BUT I really
>> suspect that 'physically' moving your typing around as you go would be
>> annoying.
>
> Indeed! When I change existing methods, I often type the new code up
> against the left margin as fast as I can (no tabs and totally
> unformatted) so I can easily _see_ which parts of the method I'm
> changing. Then before saving, I'll just use [Command+Shift+S] to
> format the whole method in one shot. I actually detest "autoIndent"
> because it gets in the way of that and mostly just complexifies the
> tabbing (sometimes you need [Tab], sometimes [Backspace], where's the
> improvement?).
>
> An alternative to this which may alleviate your performance concern
> would be to add a preference something like, "Style Continuously",
> which would do either all the time like now or only when you
> pretty-print or save the method.
>
>> Also, I'd probably like it a bit more if the styling cues were a little
>> more visible to aging eyes.
>
> Have you tried the Community Theme? A lot of UI design thought went
> into it. If you don't like it, its easy to customize a theme for your
> eyes.
>
>> auto-indent actually seems to work ok for my usage but I imagine it might
>> be something that could work with a styler to help keep formatting nice.
>
> What I want is to be able to use Command+Shift+S on only the
> *selected* code instead of the whole method. It seemed like a simple
> change (changeset attached) but unfortunately the compiler only
> compiles whole chunks of code that include, for example, all the
> variable definitions too, not just the partials code that was
> selected.
>