Smalltalk › Squeak › Squeak - Dev

The Inbox: Tools-LM.827.mcz

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

14 messages Options

commits-2

The Inbox: Tools-LM.827.mcz

A new version of Tools was added to project The Inbox:
http://source.squeak.org/inbox/Tools-LM.827.mcz

==================== Summary ====================

Name: Tools-LM.827
Author: LM
Time: 28 August 2018, 6:33:04.08317 pm
UUID: 07abf38e-4d17-8744-bd3d-e65285f5fb8f
Ancestors: Tools-cmm.826

I would like to propose a change to the Workspace that simply enables syntax highlighting by default.

Maybe there are reasons why syntax highlighting should be disabled, but in my year of Squeak experience I didn't once write anything other than code into the Workspace and it was very annoying to have to enable syntax highlighting manually all the time.

=============== Diff against Tools-cmm.826 ===============

Item was changed:
----- Method: Workspace>>initialize (in category 'initialize-release') -----
initialize

super initialize.
self initializeBindings.
acceptDroppedMorphs := false.
mustDeclareVariables := false.
+ environment := Environment current.
+ self shouldStyle: true!
- environment := Environment current.!

timrowledge

Re: The Inbox: Tools-LM.827.mcz

This is why I would prefer not to see this change -

On 2018-08-28, at 9:33 AM, [hidden email] wrote:

A new version of Tools was added to project The Inbox:
http://source.squeak.org/inbox/Tools-LM.827.mcz

==================== Summary ====================

Name: Tools-LM.827
Author: LM
Time: 28 August 2018, 6:33:04.08317 pm
UUID: 07abf38e-4d17-8744-bd3d-e65285f5fb8f
Ancestors: Tools-cmm.826

I would like to propose a change to the Workspace that simply enables syntax highlighting by default.

Maybe there are reasons why syntax highlighting should be disabled, but in my year of Squeak experience I didn't once write anything other than code into the Workspace and it was very annoying to have to enable syntax highlighting manually all the time.

=============== Diff against Tools-cmm.826 ===============

Item was changed:
----- Method: Workspace>>initialize (in category 'initialize-release') -----
initialize

super initialize.
self initializeBindings.
acceptDroppedMorphs := false.
mustDeclareVariables := false.
+ environment := Environment current.
+ self shouldStyle: true!
- environment := Environment current.!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: RIW: Re-Invent Wheel

Eliot Miranda-2

Re: The Inbox: Tools-LM.827.mcz

Hi Both, Hi All,

On Tue, Aug 28, 2018 at 10:09 AM tim Rowledge <[hidden email]> wrote:

This is why I would prefer not to see this change -

In Pharo's Playground errors in syntax highlighting are reset after a new line (see below). So one only sees one line of red before syntax highlighting works as desired again. This makes it bearable. So if we are to enable syntax highlighting by default can we first create a subclass or mode of the Shout styler that resets its parse after a new line where preceding characters have been marked as in error? Note also that the results of doit are inserted into the text as comments.

On 2018-08-28, at 9:33 AM, [hidden email] wrote:

A new version of Tools was added to project The Inbox:
http://source.squeak.org/inbox/Tools-LM.827.mcz

==================== Summary ====================

Name: Tools-LM.827
Author: LM
Time: 28 August 2018, 6:33:04.08317 pm
UUID: 07abf38e-4d17-8744-bd3d-e65285f5fb8f
Ancestors: Tools-cmm.826

I would like to propose a change to the Workspace that simply enables syntax highlighting by default.

Maybe there are reasons why syntax highlighting should be disabled, but in my year of Squeak experience I didn't once write anything other than code into the Workspace and it was very annoying to have to enable syntax highlighting manually all the time.

=============== Diff against Tools-cmm.826 ===============

Item was changed:
----- Method: Workspace>>initialize (in category 'initialize-release') -----
initialize

super initialize.
self initializeBindings.
acceptDroppedMorphs := false.
mustDeclareVariables := false.
+ environment := Environment current.
+ self shouldStyle: true!
- environment := Environment current.!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: RIW: Re-Invent Wheel

_,,,^..^,,,_

best, Eliot

Screen Shot 2018-08-28 at 10.08.14 AM.png (81K) Download Attachment

Eliot Miranda-2

Re: The Inbox: Tools-LM.827.mcz

In reply to this post by timrowledge

On Tue, Aug 28, 2018 at 10:09 AM tim Rowledge <[hidden email]> wrote:

This is why I would prefer not to see this change -

[picture of Workspace with lots of red removed cuz gmail is, um, stupid]

On 2018-08-28, at 9:33 AM, [hidden email] wrote:

A new version of Tools was added to project The Inbox:
http://source.squeak.org/inbox/Tools-LM.827.mcz

==================== Summary ====================

Name: Tools-LM.827
Author: LM
Time: 28 August 2018, 6:33:04.08317 pm
UUID: 07abf38e-4d17-8744-bd3d-e65285f5fb8f
Ancestors: Tools-cmm.826

I would like to propose a change to the Workspace that simply enables syntax highlighting by default.

Maybe there are reasons why syntax highlighting should be disabled, but in my year of Squeak experience I didn't once write anything other than code into the Workspace and it was very annoying to have to enable syntax highlighting manually all the time.

=============== Diff against Tools-cmm.826 ===============

Item was changed:
----- Method: Workspace>>initialize (in category 'initialize-release') -----
initialize

super initialize.
self initializeBindings.
acceptDroppedMorphs := false.
mustDeclareVariables := false.
+ environment := Environment current.
+ self shouldStyle: true!
- environment := Environment current.!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: RIW: Re-Invent Wheel

_,,,^..^,,,_

best, Eliot

Screen Shot 2018-08-28 at 10.08.14 AM.png (81K) Download Attachment

Eliot Miranda-2

Re: The Inbox: Tools-LM.827.mcz

In reply to this post by timrowledge

[?!$#%& third attempt to insert the graphic; sorry!]

On Aug 28, 2018, at 10:09 AM, tim Rowledge <[hidden email]> wrote:

This is why I would prefer not to see this change -
<Screen Shot 2018-08-28 at 10.08.14 AM.png>

On 2018-08-28, at 9:33 AM, [hidden email] wrote:

A new version of Tools was added to project The Inbox:
http://source.squeak.org/inbox/Tools-LM.827.mcz

==================== Summary ====================

Name: Tools-LM.827
Author: LM
Time: 28 August 2018, 6:33:04.08317 pm
UUID: 07abf38e-4d17-8744-bd3d-e65285f5fb8f
Ancestors: Tools-cmm.826

I would like to propose a change to the Workspace that simply enables syntax highlighting by default.

Maybe there are reasons why syntax highlighting should be disabled, but in my year of Squeak experience I didn't once write anything other than code into the Workspace and it was very annoying to have to enable syntax highlighting manually all the time.

=============== Diff against Tools-cmm.826 ===============

Item was changed:
----- Method: Workspace>>initialize (in category 'initialize-release') -----
initialize

super initialize.
self initializeBindings.
acceptDroppedMorphs := false.
mustDeclareVariables := false.
+ environment := Environment current.
+ self shouldStyle: true!
- environment := Environment current.!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: RIW: Re-Invent Wheel

timrowledge

Re: The Inbox: Tools-LM.827.mcz

In reply to this post by Eliot Miranda-2

> On 2018-08-28, at 11:03 AM, Eliot Miranda <[hidden email]> wrote:
>
> Hi Both, Hi All,
> On Tue, Aug 28, 2018 at 10:09 AM tim Rowledge <[hidden email]> wrote:
> This is why I would prefer not to see this change -

[snip large image]
>
> In Pharo's Playground errors in syntax highlighting are reset after a new line (see below). So one only sees one line of red before syntax highlighting works as desired again. This makes it bearable. So if we are to enable syntax highlighting by default can we first create a subclass or mode of the Shout styler that resets its parse after a new line where preceding characters have been marked as in error? Note also that the results of doit are inserted into the text as comments.

This actually refers back to some Help Browser stuff I posted a while back; being able to mark some text as CodeStyledStyle (for want of a better description).

We could do a simple version where you select text, have it styled by Shout (if there are multiple sorts of styling, offer those options) and you get back the text styled with the normal bold/colour/etc stuff. That would be quite nice for static or nearly static text - in help pages for example.

Better of course would be a styling form that is active and, just as typing into the middle of a bold section makes the new letters bold, as you type it updates the styling to stay code styled rather than just whatever you happen to be typing into.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Breakthrough: It finally booted on the first try.

Leon Matthes

Re: The Inbox: Tools-LM.827.mcz

In reply to this post by Eliot Miranda-2

Eliot Miranda-2 wrote
> In Pharo's Playground errors in syntax highlighting are reset after a new
> line (see below). So one only sees one line of red before syntax
> highlighting works as desired again. This makes it bearable. So if we
> are to enable syntax highlighting by default can we first create a
> subclass or mode of the Shout styler that resets its parse after a new
> line where preceding characters have been marked as in error? Note also
> that the results of doit are inserted into the text as comments.

Does this also work with formatted code? for example cascades that span
multiple lines.

timrowledge wrote
> This is why I would prefer not to see this change -
<http://forum.world.st/attachment/5083803/0/Screen%20Shot%202018-08-28%20at%2010.08.14%20AM.png>

Okay, I see your problem.
Do you usually stick to one form of highlighting, either on or off, for all
your Workspaces?
Because if this is the case, I would suggest to save whether the user wants
to enable code styling whenever Workspace>>#toggleStyling is called and to
just use the saved state whenever a new Workspace is created, instead of
relying on one default.
This would allow people like me who almost always want syntax highlighting
to just enable it once and everyone else to just keep it at the default.

Kind regards,
Leon (original author of the commit)

--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

Leon Matthes

Re: The Inbox: Tools-LM.827.mcz

In reply to this post by commits-2

Oh sorry everyone, while digging around in the Workspace(class) code, I just
discovered that there actually is a system preference to enable styling in
Workspaces by default...

Sorry to bother you guys, this makes my commit kind of pointless

Only thing I would still like to add, is that it might be good to change the
description of this preference to something that makes it clear that "Shout
styling" means smalltalk syntax highlighting, as this might not be obvious
to someone who is not fairly familiar with the implementation of the
Smalltalk compiler toolchain. This is probably also the reason why I never
discovered the option before :P

Regards,
Leon

--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

Eliot Miranda-2

Re: The Inbox: Tools-LM.827.mcz

In reply to this post by Leon Matthes

Hi Leon,

> On Aug 28, 2018, at 12:12 PM, Leon Matthes <[hidden email]> wrote:
>
> Eliot Miranda-2 wrote
>> In Pharo's Playground errors in syntax highlighting are reset after a new
>> line (see below). So one only sees one line of red before syntax
>> highlighting works as desired again. This makes it bearable. So if we
>> are to enable syntax highlighting by default can we first create a
>> subclass or mode of the Shout styler that resets its parse after a new
>> line where preceding characters have been marked as in error? Note also
>> that the results of doit are inserted into the text as comments.
>
> Does this also work with formatted code? for example cascades that span
> multiple lines.

Yes it does. I *think* the algorithm is to reset the next line when the current levels be is in error. But I would check out Pharo to see how it’s really done.

> timrowledge wrote
>> This is why I would prefer not to see this change -
> <http://forum.world.st/attachment/5083803/0/Screen%20Shot%202018-08-28%20at%2010.08.14%20AM.png>
>
> Okay, I see your problem.
> Do you usually stick to one form of highlighting, either on or off, for all
> your Workspaces?
> Because if this is the case, I would suggest to save whether the user wants
> to enable code styling whenever Workspace>>#toggleStyling is called and to
> just use the saved state whenever a new Workspace is created, instead of
> relying on one default.
> This would allow people like me who almost always want syntax highlighting
> to just enable it once and everyone else to just keep it at the default.
>
> Kind regards,
> Leon (original author of the commit)
>
>
>
> --
> Sent from: http://forum.world.st/Squeak-Dev-f45488.html
>

David T. Lewis

Re: The Inbox: Tools-LM.827.mcz

In reply to this post by Leon Matthes

On Tue, Aug 28, 2018 at 02:23:59PM -0500, Leon Matthes wrote:

> Oh sorry everyone, while digging around in the Workspace(class) code, I just
> discovered that there actually is a system preference to enable styling in
> Workspaces by default...
>
> Sorry to bother you guys, this makes my commit kind of pointless
>
> Only thing I would still like to add, is that it might be good to change the
> description of this preference to something that makes it clear that "Shout
> styling" means smalltalk syntax highlighting, as this might not be obvious
> to someone who is not fairly familiar with the implementation of the
> Smalltalk compiler toolchain. This is probably also the reason why I never
> discovered the option before :P
>
> Regards,
> Leon

That is a very good idea. The preference makes much more sense to me when
the description is changed as you suggest:

Workspace class>>shouldStyle
<preference: 'Smalltalk syntax styling in Workspace'
category: 'browsing'
description: 'If true, new workspaces use Shout to style their contents.'
type: #Boolean>
^ ShouldStyle ifNil: [ false ]

Dave

Hannes Hirzel

Re: The Inbox: Tools-LM.827.mcz

On 8/29/18, David T. Lewis <[hidden email]> wrote:

> On Tue, Aug 28, 2018 at 02:23:59PM -0500, Leon Matthes wrote:
>> Oh sorry everyone, while digging around in the Workspace(class) code, I
>> just
>> discovered that there actually is a system preference to enable styling in
>> Workspaces by default...
>>
>> Sorry to bother you guys, this makes my commit kind of pointless
>>
>> Only thing I would still like to add, is that it might be good to change
>> the
>> description of this preference to something that makes it clear that
>> "Shout
>> styling" means smalltalk syntax highlighting, as this might not be obvious
>> to someone who is not fairly familiar with the implementation of the
>> Smalltalk compiler toolchain. This is probably also the reason why I never
>> discovered the option before :P
>>
>> Regards,
>> Leon
>
> That is a very good idea. The preference makes much more sense to me when
> the description is changed as you suggest:
>
> Workspace class>>shouldStyle
> <preference: 'Smalltalk syntax styling in Workspace'
> category: 'browsing'
> description: 'If true, new workspaces use Shout to style their contents.'
> type: #Boolean>
> ^ ShouldStyle ifNil: [ false ]
>
> Dave

+1 for a preference which explains what it is about, 'shout' is not explanatory.

I suggest to choose a description which matches the menu entry (see screen shot)

Smalltalk syntax highlighting in Workspaces

* * *

An additional idea which probably should be discussed in another
thread is to have the Syntax highlighting only work if the code is
indented four spaces. Otherwise the content would be considered
explanatory text.

Many markdown systems have this convention, including github (e.g.
describing issues with text and code)

In addition this convention would have the advantage that a
conversion method to markdown is easy to implement [4]

In Juypter notebooks a dynamic notebook is a sequence of text boxes
and code boxes (they are called cells). [1]

Maybe we can mimic something like that as well in a Smalltalk workspace.

A well written workspace with code examples may be considered Active
Content or a simple form of an Active Essay [2]

Thus a Squeak image with several projects and many workspaces may be
considered a 'Dynabook' [3]

-- Hannes

[1] Jupyter notebooks http://wiki.squeak.org/squeak/1318
[2] Active Essays http://wiki.squeak.org/squeak/3307
[3] Personal Dynamic Media http://wiki.squeak.org/squeak/1070
[4] And for example add a menu to the workspace to export the content
to a github gist
(not for 5.2)

Squeak5.2_syntax_hightlighting_in_workspaces_Screenshot_from_2018-08-29.png (54K) Download Attachment

Tim Johnson-2

Re: The Inbox: Tools-LM.827.mcz

In reply to this post by commits-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 Aug 28, 2018, at 9:33 AM, [hidden email] wrote:
>
> A new version of Tools was added to project The Inbox:
> http://source.squeak.org/inbox/Tools-LM.827.mcz
>
> ==================== Summary ====================
>
> Name: Tools-LM.827
> Author: LM
> Time: 28 August 2018, 6:33:04.08317 pm
> UUID: 07abf38e-4d17-8744-bd3d-e65285f5fb8f
> Ancestors: Tools-cmm.826
>
> I would like to propose a change to the Workspace that simply enables syntax highlighting by default.
>
> Maybe there are reasons why syntax highlighting should be disabled, but in my year of Squeak experience I didn't once write anything other than code into the Workspace and it was very annoying to have to enable syntax highlighting manually all the time.
>
> =============== Diff against Tools-cmm.826 ===============
>
> Item was changed:
> ----- Method: Workspace>>initialize (in category 'initialize-release') -----
> initialize
>
> super initialize.
> self initializeBindings.
> acceptDroppedMorphs := false.
> mustDeclareVariables := false.
> + environment := Environment current.
> + self shouldStyle: true!
> - environment := Environment current.!
>
>
>

Hannes Hirzel

Re: The Inbox: Tools-LM.827.mcz

On 8/29/18, Tim Johnson <[hidden email]> wrote:

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

URL = ?

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.

+1

> Thanks,
> Tim
>
>
>
>> On Aug 28, 2018, at 9:33 AM, [hidden email] wrote:
>>
>> A new version of Tools was added to project The Inbox:
>> http://source.squeak.org/inbox/Tools-LM.827.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Tools-LM.827
>> Author: LM
>> Time: 28 August 2018, 6:33:04.08317 pm
>> UUID: 07abf38e-4d17-8744-bd3d-e65285f5fb8f
>> Ancestors: Tools-cmm.826
>>
>> I would like to propose a change to the Workspace that simply enables
>> syntax highlighting by default.
>>
>> Maybe there are reasons why syntax highlighting should be disabled, but in
>> my year of Squeak experience I didn't once write anything other than code
>> into the Workspace and it was very annoying to have to enable syntax
>> highlighting manually all the time.
>>
>> =============== Diff against Tools-cmm.826 ===============
>>
>> Item was changed:
>> ----- Method: Workspace>>initialize (in category 'initialize-release')
>> -----
>> initialize
>>
>> super initialize.
>> self initializeBindings.
>> acceptDroppedMorphs := false.
>> mustDeclareVariables := false.
>> + environment := Environment current.
>> + self shouldStyle: true!
>> - environment := Environment current.!
>>
>>
>>
>
>
>

Tim Johnson-2

Re: The Inbox: Tools-LM.827.mcz

On Aug 29, 2018, at 7:57 AM, H. Hirzel <[hidden email]> wrote:

On 8/29/18, Tim Johnson <[hidden email]> wrote:
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.

URL = ?

URL := http://forum.world.st/Proof-of-concept-moving-Smalltalk-code-editing-support-into-SmalltalkEditor-td5071631.html

Thanks,

Tim J