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

On Mar 25, 2018, at 11:18 PM, Marcel Taeumel marcel.taeumel@hpi.de 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 digit@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.

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.

On 25-03-2018, at 8:52 PM, Chris Muller asqueaker@gmail.com 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; tim@rowledge.org; http://www.rowledge.org/tim Diagnostics are the programs that run when nothing else will.

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 marcel.taeumel@hpi.de 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 tim@rowledge.org:

...

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; tim@rowledge.org; http://www.rowledge.org/tim Diagnostics are the programs that run when nothing else will.

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 asqueaker@gmail.com 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.

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; tim@rowledge.org; http://www.rowledge.org/tim All new: The software is not compatible with previous versions.

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 asqueaker@gmail.com 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.