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.!
This is why I would prefer not to see this change -
On 2018-08-28, at 9:33 AM, commits@source.squeak.org 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; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RIW: Re-Invent Wheel
Hi Both, Hi All, On Tue, Aug 28, 2018 at 10:09 AM tim Rowledge tim@rowledge.org 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, commits@source.squeak.org 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; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RIW: Re-Invent Wheel
On 2018-08-28, at 11:03 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Both, Hi All, On Tue, Aug 28, 2018 at 10:09 AM tim Rowledge tim@rowledge.org 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; tim@rowledge.org; http://www.rowledge.org/tim Breakthrough: It finally booted on the first try.
On Tue, Aug 28, 2018 at 10:09 AM tim Rowledge tim@rowledge.org 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]
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, commits@source.squeak.org 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; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RIW: Re-Invent Wheel
[?!$#%& third attempt to insert the graphic; sorry!]
On Aug 28, 2018, at 10:09 AM, tim Rowledge tim@rowledge.org wrote:
This is why I would prefer not to see this change - <Screen Shot 2018-08-28 at 10.08.14 AM.png>
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, commits@source.squeak.org mailto:commits@source.squeak.org wrote:
A new version of Tools was added to project The Inbox: http://source.squeak.org/inbox/Tools-LM.827.mcz 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; tim@rowledge.org mailto:tim@rowledge.org; http://www.rowledge.org/tim http://www.rowledge.org/tim Strange OpCodes: RIW: Re-Invent Wheel
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
Hi Leon,
On Aug 28, 2018, at 12:12 PM, Leon Matthes leon.matthes@student.hpi.de 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
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
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
On 8/29/18, David T. Lewis lewis@mail.msen.com 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)
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, commits@source.squeak.org 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.!
On 8/29/18, Tim Johnson digit@sonic.net 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, commits@source.squeak.org 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.!
On Aug 29, 2018, at 7:57 AM, H. Hirzel hannes.hirzel@gmail.com wrote:
On 8/29/18, Tim Johnson digit@sonic.net 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... http://forum.world.st/Proof-of-concept-moving-Smalltalk-code-editing-support-into-SmalltalkEditor-td5071631.html
Thanks, Tim J
squeak-dev@lists.squeakfoundation.org