Christoph Thiede uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-ct.999.mcz
==================== Summary ====================
Name: Collections-ct.999 Author: ct Time: 28 March 2022, 10:08:58.886426 pm UUID: d938acc0-5012-9649-960f-9b374a010b83 Ancestors: Collections-ct.998
Restores line breaks in Text codeSample that are required indeed for the FontImporterTool.
=============== Diff against Collections-ct.998 ===============
Item was changed: ----- Method: Text class>>codeSample (in category 'filler text') ----- codeSample
+ self flag: #linebreaks. "Samples are used in FontImporterTool and must contain manual linebreaks (visually stable example texts per line)." ^ 'exampleWithNumber: x + "A method that illustrates every part of Smalltalk method syntax + including primitives. It has unary, binary, and keyboard messages; + declares arguments and temporaries; accesses a global variable + (but not an instance variable); uses literals (array, nested array, + character, symbol, string, integer, float, scaled decimal, and byte + array); uses the pseudo variables nil, true, false, self, super, and + thisContext; shows that within a literal array nil, true, and false are + symbols not pseudo variables; and has sequence, assignment, + return, cascade, and tuple (array) creation. It has both zero + argument and one argument blocks, and has a block temporary." - "A method that illustrates every part of Smalltalk method syntax including primitives. It has unary, binary, and keyboard messages; declares arguments and temporaries; accesses a global variable (but not an instance variable); uses literals (array, nested array, character, symbol, string, integer, float, scaled decimal, and byte array); uses the pseudo variables nil, true, false, self, super, and thisContext; shows that within a literal array nil, true, and false are symbols not pseudo variables; and has sequence, assignment, return, cascade, and tuple (array) creation. It has both zero argument and one argument blocks, and has a block temporary." <primitive: ''primitiveCopyBits'' module: #BitBltPlugin error: ec> | y | true & false not & (nil isNil) ifFalse: [self halt]. y := self size + super size. #($a #a ''a'' "a" (1 1.0 1.0s2) nil true false), { #[65]. thisContext. nil. true. false } do: [ :each | | class | class := each class. Transcript show: (class name); show: '' '']. ^ x < y'!
Hi Christoph --
Thanks. Treat this as a piece of pre-formatted document. It is actually like source code where authors sometimes want to pre-format the linebreaks of a longer comment to not have to fiddle around with window resizing.
I know that some of us tend to remove manual line breaks in such longer comments but we might want to stop doing that if it is easy the retain the original format.
For longer comments without extra line breaks, the following preference can help programmers that have troubles reading other author's source code:
PluggableTextMorph softLineWrap: false.
PluggableTextMorph visualWrapBorder: true.
PluggableTextMorph softLineWrapAtVisualWrapBorder: true.
PluggableTextMorph visualWrapBorderLimit: 80.
That said, it would be nice to have a feature in SmalltalkEditor or TextEditor that converts the soft line breaks of the current text selection into hard line breaks and vice versa.
Then we can more easily preserve both styles of formatting longer commentary. :-)
Best, Marcel Am 28.03.2022 22:09:17 schrieb commits@source.squeak.org commits@source.squeak.org: Christoph Thiede uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-ct.999.mcz
==================== Summary ====================
Name: Collections-ct.999 Author: ct Time: 28 March 2022, 10:08:58.886426 pm UUID: d938acc0-5012-9649-960f-9b374a010b83 Ancestors: Collections-ct.998
Restores line breaks in Text codeSample that are required indeed for the FontImporterTool.
=============== Diff against Collections-ct.998 ===============
Item was changed: ----- Method: Text class>>codeSample (in category 'filler text') ----- codeSample
+ self flag: #linebreaks. "Samples are used in FontImporterTool and must contain manual linebreaks (visually stable example texts per line)." ^ 'exampleWithNumber: x + "A method that illustrates every part of Smalltalk method syntax + including primitives. It has unary, binary, and keyboard messages; + declares arguments and temporaries; accesses a global variable + (but not an instance variable); uses literals (array, nested array, + character, symbol, string, integer, float, scaled decimal, and byte + array); uses the pseudo variables nil, true, false, self, super, and + thisContext; shows that within a literal array nil, true, and false are + symbols not pseudo variables; and has sequence, assignment, + return, cascade, and tuple (array) creation. It has both zero + argument and one argument blocks, and has a block temporary." - "A method that illustrates every part of Smalltalk method syntax including primitives. It has unary, binary, and keyboard messages; declares arguments and temporaries; accesses a global variable (but not an instance variable); uses literals (array, nested array, character, symbol, string, integer, float, scaled decimal, and byte array); uses the pseudo variables nil, true, false, self, super, and thisContext; shows that within a literal array nil, true, and false are symbols not pseudo variables; and has sequence, assignment, return, cascade, and tuple (array) creation. It has both zero argument and one argument blocks, and has a block temporary."
| y | true & false not & (nil isNil) ifFalse: [self halt]. y := self size + super size. #($a #a ''a'' "a" (1 1.0 1.0s2) nil true false), { #[65]. thisContext. nil. true. false } do: [ :each | | class | class := each class. Transcript show: (class name); show: '' '']. ^ x < y'!
Hi Marcel, Christoph,
On Tue, Mar 29, 2022, 01:58 Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Christoph --
Thanks. Treat this as a piece of pre-formatted document. It is actually like source code where authors sometimes want to pre-format the linebreaks of a longer comment to not have to fiddle around with window resizing.
I know that some of us tend to remove manual line breaks in such longer comments but we might want to stop doing that if it is easy the retain the original format.
For longer comments without extra line breaks, the following preference can help programmers that have troubles reading other author's source code:
PluggableTextMorph softLineWrap: false. PluggableTextMorph visualWrapBorder: true. PluggableTextMorph softLineWrapAtVisualWrapBorder: true. PluggableTextMorph visualWrapBorderLimit: 80.
That said, it would be nice to have a feature in SmalltalkEditor or TextEditor that converts the soft line breaks of the current text selection into hard line breaks and vice versa.
Then we can more easily preserve both styles of formatting longer commentary. :-)
How about email's format=flowed? It uses a trailing space to indicate the next line can be merged and wrapped according to the viewer's preferences. We could visually mark that special end-of-line space in source mode so it's obvious, but then process it in pretty print and documentation.
This line would be merged with the rest. But this would be forced to a new one. Select the text to see the trailing blanks.
Hi Marcel, Hi Lauren,
I know that some of us tend to remove manual line breaks in such longer comments but we might want to stop doing that if it is easy the retain the original format.
I'm not yet convinced. :-) In almost all situations, I do not see any other sense in manual line breaks in comments than working around the absence of a proper line-breaking mechanism. There is (or should not be) any need for this nowadays. If we want to reduce noise on the mailing list, I would rather consider this a tooling problem.
That said, it would be nice to have a feature in SmalltalkEditor or TextEditor that converts the soft line breaks of the current text selection into hard line breaks and vice versa.
My first impression of this proposal would be that it would complicate understanding what's actually in a text vs how the text is displayed ... too many abstractions ...
Anyway, thanks for the pointers to the preferences!
How about email's format=flowed?
A problem with this could be that some systems do not preserve trailing spaces. For instance, they do not appear in the mailing list archive. :-)
Best, Christoph
--- Sent from Squeak Inbox Talk
On 2022-03-29T10:57:30-06:00, drurowin@gmail.com wrote:
Hi Marcel, Christoph,
On Tue, Mar 29, 2022, 01:58 Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
Hi Christoph --
Thanks. Treat this as a piece of pre-formatted document. It is actually like source code where authors sometimes want to pre-format the linebreaks of a longer comment to not have to fiddle around with window resizing.
I know that some of us tend to remove manual line breaks in such longer comments but we might want to stop doing that if it is easy the retain the original format.
For longer comments without extra line breaks, the following preference can help programmers that have troubles reading other author's source code:
PluggableTextMorph softLineWrap: false. PluggableTextMorph visualWrapBorder: true. PluggableTextMorph softLineWrapAtVisualWrapBorder: true. PluggableTextMorph visualWrapBorderLimit: 80.
That said, it would be nice to have a feature in SmalltalkEditor or TextEditor that converts the soft line breaks of the current text selection into hard line breaks and vice versa.
Then we can more easily preserve both styles of formatting longer commentary. :-)
How about email's format=flowed? It uses a trailing space to indicate the next line can be merged and wrapped according to the viewer's preferences. We could visually mark that special end-of-line space in source mode so it's obvious, but then process it in pretty print and documentation.
This line would be merged with the rest. But this would be forced to a new one. Select the text to see the trailing blanks.
On 1. Apr 2022, at 13:42, christoph.thiede@student.hpi.uni-potsdam.de christoph.thiede@student.hpi.uni-potsdam.de wrote:
Hi Marcel, Hi Lauren,
I know that some of us tend to remove manual line breaks in such longer comments but we might want to stop doing that if it is easy the retain the original format.
I'm not yet convinced. :-) In almost all situations, I do not see any other sense in manual line breaks in comments than working around the absence of a proper line-breaking mechanism.
I put linebreaks there because I want them exactly there :) I tend to loathe long lines. I want quite narrow text and a lot of surrounding white space.
:) -Tobias
There is (or should not be) any need for this nowadays. If we want to reduce noise on the mailing list, I would rather consider this a tooling problem.
That said, it would be nice to have a feature in SmalltalkEditor or TextEditor that converts the soft line breaks of the current text selection into hard line breaks and vice versa.
My first impression of this proposal would be that it would complicate understanding what's actually in a text vs how the text is displayed ... too many abstractions ...
Anyway, thanks for the pointers to the preferences!
How about email's format=flowed?
A problem with this could be that some systems do not preserve trailing spaces. For instance, they do not appear in the mailing list archive. :-)
Best, Christoph
Sent from Squeak Inbox Talk
On 2022-03-29T10:57:30-06:00, drurowin@gmail.com wrote:
Hi Marcel, Christoph,
On Tue, Mar 29, 2022, 01:58 Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
Hi Christoph --
Thanks. Treat this as a piece of pre-formatted document. It is actually like source code where authors sometimes want to pre-format the linebreaks of a longer comment to not have to fiddle around with window resizing.
I know that some of us tend to remove manual line breaks in such longer comments but we might want to stop doing that if it is easy the retain the original format.
For longer comments without extra line breaks, the following preference can help programmers that have troubles reading other author's source code:
PluggableTextMorph softLineWrap: false. PluggableTextMorph visualWrapBorder: true. PluggableTextMorph softLineWrapAtVisualWrapBorder: true. PluggableTextMorph visualWrapBorderLimit: 80.
That said, it would be nice to have a feature in SmalltalkEditor or TextEditor that converts the soft line breaks of the current text selection into hard line breaks and vice versa.
Then we can more easily preserve both styles of formatting longer commentary. :-)
How about email's format=flowed? It uses a trailing space to indicate the next line can be merged and wrapped according to the viewer's preferences. We could visually mark that special end-of-line space in source mode so it's obvious, but then process it in pretty print and documentation.
This line would be merged with the rest. But this would be forced to a new one. Select the text to see the trailing blanks.
Hi Christoph, Marcel, Tobias,
My proposal is to not include the documentation in a comment at all.
Add a dedicated text box to the browser for the comment and treat method comments like class comments, but then display both code and documentation simultaneously side by side. Then there could be completely different rules for formatting text from formatting code. I want each text line to be narrow... but I want each code line to be able to be wide to take advantage of indentation.
On 4/1/22 11:42, christoph.thiede@student.hpi.uni-potsdam.de wrote:
How about email's format=flowed?
A problem with this could be that some systems do not preserve trailing spaces. For instance, they do not appear in the mailing list archive. :-)
Unrelated, I checked my copy of the sent mail and it looks like my client stripped the trailing spaces when it got sent to prepare it for the ml archive.
This might be a problem with the inlined diffs that get sent out when people save new versions, but I still think it's the least intrusive option and doesn't require any special non-space-bar spaces. It wouldn't affect code samples in the comments, and you could detect paragraphs all on one literal line by the period-return-return and period-endOfComment patterns.
If you press return you get a normal line break (for people like Tobias and myself, who put in line breaks because they're supposed to be there), and if you hit the space bar right before that it signals the comment formatting engine to use the user's preference to change the line widths.
Hi Tobias, Hi Lauren,
I put linebreaks there because I want them exactly there :)
But then you are talking more about paragraphs rather than linebreaks, aren't you? :-)
A comment like this is totally fine to me:
terminate "Stop the receiver forever. Run all unwind contexts (#ensure:/#ifCurtailed: blocks) on the stack, even if they are currently in progress. If already active unwind contexts should not be continued, send #terminateAggressively instead. NOTE THAT bla bla bla!"
But not this:
terminate "Stop the receiver forever. Run all unwind contexts (#ensure:/#ifCurtailed: blocks) on the stack, even if they are currently in progress. If already active unwind contexts should not be continued, send #terminateAggressively instead. NOTE THAT bla bla bla!"
In the second example, we would just stupidically do the work of the text composer. Similar to the "tabs vs spaces" debate, spaces/manual linebreaks prescribe the appearance of the code/text, whereas tabs/automatic line-breaking leave this decision to the tooling of the reader or author. If I resize my browser window, I would like its contents to be re-layouted as flexibly as possible.
Even worse, manual linebreaks blur the differences between semantically distinct paragraphs and composition-specific linebreaks.
@Lauren:
My proposal is to not include the documentation in a comment at all.
I think you are neglecting comments in the midst of any method, which occur pretty frequently in Squeak and are an important part of Smalltalk programming IMHO. :)
Best, Christoph
--- Sent from Squeak Inbox Talk
On 2022-04-01T16:06:01+00:00, drurowin@gmail.com wrote:
Hi Christoph, Marcel, Tobias,
My proposal is to not include the documentation in a comment at all.
Add a dedicated text box to the browser for the comment and treat method comments like class comments, but then display both code and documentation simultaneously side by side. Then there could be completely different rules for formatting text from formatting code. I want each text line to be narrow... but I want each code line to be able to be wide to take advantage of indentation.
On 4/1/22 11:42, christoph.thiede at student.hpi.uni-potsdam.de wrote:
How about email's format=flowed?
A problem with this could be that some systems do not preserve trailing spaces. For instance, they do not appear in the mailing list archive. :-)
Unrelated, I checked my copy of the sent mail and it looks like my client stripped the trailing spaces when it got sent to prepare it for the ml archive.
This might be a problem with the inlined diffs that get sent out when people save new versions, but I still think it's the least intrusive option and doesn't require any special non-space-bar spaces. It wouldn't affect code samples in the comments, and you could detect paragraphs all on one literal line by the period-return-return and period-endOfComment patterns.
If you press return you get a normal line break (for people like Tobias and myself, who put in line breaks because they're supposed to be there), and if you hit the space bar right before that it signals the comment formatting engine to use the user's preference to change the line widths.
Hi Christoph,
On 4/1/22 16:35, christoph.thiede@student.hpi.uni-potsdam.de wrote:
My proposal is to not include the documentation in a comment at all.
I think you are neglecting comments in the midst of any method, which occur pretty frequently in Squeak and are an important part of Smalltalk programming IMHO. :)
(I knew I should have put that in! :)
I'm all for putting comments inside the method. I just think there's a distinction between the user documentation and inlined notes. An inlined note is a string that gets thrown away by the parser but otherwise appears exactly as written. User documentation is text and gets formatted by the user's preferences.
Hi Christoph, Tobias, Lauren, all
A comment like this is totally fine to me:
terminate "Stop the receiver forever. Run all unwind contexts (#ensure:/#ifCurtailed: blocks) on the stack, even if they are currently in progress. If already active unwind contexts should not be continued, send #terminateAggressively instead. NOTE THAT bla bla bla!"
I dare to disagree here – this looks distracting to me. Dolphin solved this by indenting long lines to make them into a tidy indented paragraph.
But not this:
terminate "Stop the receiver forever. Run all unwind contexts (#ensure:/#ifCurtailed: blocks) on the stack, even if they are currently in progress. If already active unwind contexts should not be continued, send #terminateAggressively instead. NOTE THAT bla bla bla!"
Unless Squeak somehow employs a reasonable indentation I personally prefer this way – especially for comments inside the indented code – long lines break indentation and the resulting look is unfortunate; I’m trying to avoid long comments but sometimes a longer comment just feels appropriate.
I put linebreaks there because I want them exactly there :)
Yes, I do that too… to manually enforce indentation, really.
I’ve noticed VW are struggling with the same dilemma too :)
My proposal is to not include the documentation in a comment at all.
I’m not sure how to understand that; I’ve recently worked on a few methods (#terminate etc.) where I felt the need to add as much comment text as possible… even more comment than code :) Would that be considered a “documentation”? Where else to put it?
Thanks,
--
Jaromír Matas
mail@jaromir.net
From: christoph.thiede@student.hpi.uni-potsdam.demailto:christoph.thiede@student.hpi.uni-potsdam.de Sent: Friday, April 1, 2022 18:35 To: squeak-dev@lists.squeakfoundation.orgmailto:squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Manual line breaks in code
Hi Tobias, Hi Lauren,
I put linebreaks there because I want them exactly there :)
But then you are talking more about paragraphs rather than linebreaks, aren't you? :-)
A comment like this is totally fine to me:
terminate "Stop the receiver forever. Run all unwind contexts (#ensure:/#ifCurtailed: blocks) on the stack, even if they are currently in progress. If already active unwind contexts should not be continued, send #terminateAggressively instead. NOTE THAT bla bla bla!"
But not this:
terminate "Stop the receiver forever. Run all unwind contexts (#ensure:/#ifCurtailed: blocks) on the stack, even if they are currently in progress. If already active unwind contexts should not be continued, send #terminateAggressively instead. NOTE THAT bla bla bla!"
In the second example, we would just stupidically do the work of the text composer. Similar to the "tabs vs spaces" debate, spaces/manual linebreaks prescribe the appearance of the code/text, whereas tabs/automatic line-breaking leave this decision to the tooling of the reader or author. If I resize my browser window, I would like its contents to be re-layouted as flexibly as possible.
Even worse, manual linebreaks blur the differences between semantically distinct paragraphs and composition-specific linebreaks.
@Lauren:
My proposal is to not include the documentation in a comment at all.
I think you are neglecting comments in the midst of any method, which occur pretty frequently in Squeak and are an important part of Smalltalk programming IMHO. :)
Best, Christoph
--- Sent from Squeak Inbox Talkhttps://github.com/hpi-swa-lab/squeak-inbox-talk
On 2022-04-01T16:06:01+00:00, drurowin@gmail.com wrote:
Hi Christoph, Marcel, Tobias,
My proposal is to not include the documentation in a comment at all.
Add a dedicated text box to the browser for the comment and treat method comments like class comments, but then display both code and documentation simultaneously side by side. Then there could be completely different rules for formatting text from formatting code. I want each text line to be narrow... but I want each code line to be able to be wide to take advantage of indentation.
On 4/1/22 11:42, christoph.thiede at student.hpi.uni-potsdam.de wrote:
How about email's format=flowed?
A problem with this could be that some systems do not preserve trailing spaces. For instance, they do not appear in the mailing list archive. :-)
Unrelated, I checked my copy of the sent mail and it looks like my client stripped the trailing spaces when it got sent to prepare it for the ml archive.
This might be a problem with the inlined diffs that get sent out when people save new versions, but I still think it's the least intrusive option and doesn't require any special non-space-bar spaces. It wouldn't affect code samples in the comments, and you could detect paragraphs all on one literal line by the period-return-return and period-endOfComment patterns.
If you press return you get a normal line break (for people like Tobias and myself, who put in line breaks because they're supposed to be there), and if you hit the space bar right before that it signals the comment formatting engine to use the user's preference to change the line widths.
On 2022-04-01, at 1:30 PM, Jaromir Matas mail@jaromir.net wrote:
Unless Squeak somehow employs a reasonable indentation I personally prefer this way – especially for comments inside the indented code – long lines break indentation and the resulting look is unfortunate; I’m trying to avoid long comments but sometimes a longer comment just feels appropriate.
Perhaps one might do some extensions to Shout to format comments to your preferences? It already detects comments, obviously, so maybe making it possible to have a text style applied in just the right manner?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Attitudes are contagious. Mine might kill you
On Fri, Apr 01, 2022 at 02:32:04PM -0700, tim Rowledge wrote:
On 2022-04-01, at 1:30 PM, Jaromir Matas mail@jaromir.net wrote:
Unless Squeak somehow employs a reasonable indentation I personally prefer this way ??? especially for comments inside the indented code ??? long lines break indentation and the resulting look is unfortunate; I???m trying to avoid long comments but sometimes a longer comment just feels appropriate.
Perhaps one might do some extensions to Shout to format comments to your preferences? It already detects comments, obviously, so maybe making it possible to have a text style applied in just the right manner?
Yes please. If someone wants to format comments differently, then pretty print it any way you like. Shout might be good for doing that.
There are a lot of things that might be done to improve the quality and quantity of comments in Squeak. Messing around with line break characters in other people's comments is not one of those things. Please just don't.
Dave
There are a lot of things that might be done to improve the quality and quantity of comments in Squeak. Messing around with line break characters in other people's comments is not one of those things. Please just don't.
+1
Comments in Squeak are wonderfully simple: just write whatever you want wherever you want. Comment out whatever chunk of code, anywhere, easily. Prepare code in comment to be used only within a debugger - there are many ways to play with the comments syntax. Please do not take this simplicity and the freedom it allows away from us, and remember that no two coders have the same pratices and preferences. When possible, we should allow all styles.
Stef
Hi all,
Yes please. If someone wants to format comments differently, then pretty print it any way you like. Shout might be good for doing that.
+1. I'd just argue that inserting linebreaks via pretty print is significantly easier than removing them.
It just does not have a readable shape.
So would you be fine some kind of MaximumCompositionWidthAttribute that your Shout could apply to any comment in the source code? :-)
When possible, we should allow all styles.
Yes, ping-pong commits are bad, but inconsistency isn't beautiful, either. I think we still are missing a proper pretty-printer that fits everyone's individual needs and can release us from debates like this one. :D
Best, Christoph
PS: Please find another very typical argument against pre-formatted text with manual linebreaks in the attachment. It's really annoying to me. :-)
--- Sent from Squeak Inbox Talk
On 2022-04-02T11:34:36+02:00, lecteur@zogotounga.net wrote:
There are a lot of things that might be done to improve the quality and quantity of comments in Squeak. Messing around with line break characters in other people's comments is not one of those things. Please just don't.
+1
Comments in Squeak are wonderfully simple: just write whatever you want wherever you want. Comment out whatever chunk of code, anywhere, easily. Prepare code in comment to be used only within a debugger - there are many ways to play with the comments syntax. Please do not take this simplicity and the freedom it allows away from us, and remember that no two coders have the same pratices and preferences. When possible, we should allow all styles.
Stef
["manualLinebreaks.png"]
Hi,
I assume that there are more valuable things to discuss than the formatting, auto-formatting, and auto-formatability of comments. Perfectionism and engineering are probably better spent in other places.
If you encounter a comment or text with manual line breaks and are deterred by the gaps introduced by automatic line wrapping, you can always enlarge the text view (temporarily) so that the line breaks fit, can't you?
Kind regards, Jakob
Am Sa., 2. Apr. 2022 um 13:56 Uhr schrieb christoph.thiede@student.hpi.uni-potsdam.de:
Hi all,
Yes please. If someone wants to format comments differently, then pretty print it any way you like. Shout might be good for doing that.
+1. I'd just argue that inserting linebreaks via pretty print is significantly easier than removing them.
It just does not have a readable shape.
So would you be fine some kind of MaximumCompositionWidthAttribute that your Shout could apply to any comment in the source code? :-)
When possible, we should allow all styles.
Yes, ping-pong commits are bad, but inconsistency isn't beautiful, either. I think we still are missing a proper pretty-printer that fits everyone's individual needs and can release us from debates like this one. :D
Best, Christoph
PS: Please find another very typical argument against pre-formatted text with manual linebreaks in the attachment. It's really annoying to me. :-)
Sent from Squeak Inbox Talk
On 2022-04-02T11:34:36+02:00, lecteur@zogotounga.net wrote:
There are a lot of things that might be done to improve the quality and quantity of comments in Squeak. Messing around with line break characters in other people's comments is not one of those things. Please just don't.
+1
Comments in Squeak are wonderfully simple: just write whatever you want wherever you want. Comment out whatever chunk of code, anywhere, easily. Prepare code in comment to be used only within a debugger - there are many ways to play with the comments syntax. Please do not take this simplicity and the freedom it allows away from us, and remember that no two coders have the same pratices and preferences. When possible, we should allow all styles.
Stef
["manualLinebreaks.png"]
Hi
On 2. Apr 2022, at 13:55, christoph.thiede@student.hpi.uni-potsdam.de christoph.thiede@student.hpi.uni-potsdam.de wrote:
Hi all,
Yes please. If someone wants to format comments differently, then pretty print it any way you like. Shout might be good for doing that.
+1. I'd just argue that inserting linebreaks via pretty print is significantly easier than removing them.
It just does not have a readable shape.
So would you be fine some kind of MaximumCompositionWidthAttribute that your Shout could apply to any comment in the source code? :-)
Not at all. Just leave my linebreaks alone. I don't pretend to be a better Knuth-Plass but please don't force an algorithm on prose I write…
When possible, we should allow all styles.
Yes, ping-pong commits are bad, but inconsistency isn't beautiful, either. I think we still are missing a proper pretty-printer that fits everyone's individual needs and can release us from debates like this one. :D
Best, Christoph
PS: Please find another very typical argument against pre-formatted text with manual linebreaks in the attachment. It's really annoying to me. :-)
Well, it was obviously written with a larger width in mind. The solution is: make the window wider.
Most the text we have has insufficient margins anyway…
-t
Sent from Squeak Inbox Talk
On 2022-04-02T11:34:36+02:00, lecteur@zogotounga.net wrote:
There are a lot of things that might be done to improve the quality and quantity of comments in Squeak. Messing around with line break characters in other people's comments is not one of those things. Please just don't.
+1
Comments in Squeak are wonderfully simple: just write whatever you want wherever you want. Comment out whatever chunk of code, anywhere, easily. Prepare code in comment to be used only within a debugger - there are many ways to play with the comments syntax. Please do not take this simplicity and the freedom it allows away from us, and remember that no two coders have the same pratices and preferences. When possible, we should allow all styles.
Stef
["manualLinebreaks.png"]<manualLinebreaks.png>
On 2022-04-02, at 6:51 AM, Tobias Pape Das.Linux@gmx.de wrote:
Well, it was obviously written with a larger width in mind. The solution is: make the window wider.
Some of us are so old the *screen* was only 640*400 (and monochrome, with snow in both directions!) and so that wasn't a very viable solution.
More seriously, why not enhance Shout to do something very like the Dolphin screenshots Jaromir posted? It's there, it futzes with the code to colorise/fontify it, why not?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Sweet sorrow
I feel reminded of some recent discussions about pretty-printing. Some people apparently want to control every detail of the appearance of their source code (line-breaking, text composition etc.), whereas others see this as a burden and prefer to focus on the content only (i.e., the Smalltalk AST & the natural language AST of comments).
Perfectionism and engineering are probably better spent in other places.
+1
Some of us are so old the *screen* was only 640*400 (and monochrome, with snow in both directions!) and so that wasn't a very viable solution.
+1. Additionally, even on modern screens, I very much prefer to have the full control over the layout of my windows. I often have ten or more open windows on my screen at the same time, next to each other, and it is pretty annoying when up to 199% of the space are wasted through redundant line breaks.
More seriously, why not enhance Shout to do something very like the Dolphin screenshots Jaromir posted? It's there, it futzes with the code to colorise/fontify it, why not?
+1. And maybe let's make it configurable. :-)
Best, Christoph
--- Sent from Squeak Inbox Talk
On 2022-04-02T10:15:38-07:00, tim@rowledge.org wrote:
On 2022-04-02, at 6:51 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
Well, it was obviously written with a larger width in mind. The solution is: make the window wider.
Some of us are so old the *screen* was only 640*400 (and monochrome, with snow in both directions!) and so that wasn't a very viable solution.
More seriously, why not enhance Shout to do something very like the Dolphin screenshots Jaromir posted? It's there, it futzes with the code to colorise/fontify it, why not?
tim
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Oxymorons: Sweet sorrow
I feel reminded of some recent discussions about pretty-printing. Some people apparently want to control every detail of the appearance of their source code (line-breaking, text composition etc.),
I would be one of these people, but I would say it otherwise:
when I layout my code, and my comments, I am writing for another human being (most probably myself in the future). And when I read source code, and comments therein, I read what another human being has written.
Indentation, line breaks, etc all convey some meaning (otherwise we would not even bother about formatting in the first place).
To assume that an algorithm can properly "pretty-print" a hunman output intended to another human, we must assume that nothing is lost in the process.
Now if "details" did not matter, I could have said:
I would be one of these people, but I would say it otherwise: when I layout my code, and my comments, I am writing for another human being (most probably myself in the future). And when I read source code, and comments therein, I read what another human being has written. Indentation, line breaks, etc all convey some meaning (otherwise we would not even bother about formatting in the first place). To assume that an algorithm can properly "pretty-print" a hunman output intended to another human, we must assume that nothing is lost in the process. Or maybe I could have said: I would be one of these people, but I would say it otherwise: when I layout my code, and my comments, I am writing for another human being (most probably myself in the future). And when I read source code, and comments therein, I read what another human being has written. Indentation, line breaks, etc all convey some meaning (otherwise we would not even bother about formatting in the first place). To assume that an algorithm can properly "pretty-print" a hunman output intended to another human, we must assume that nothing is lost in the process.
But to me, these details matter.
Stef
Hi Stef,
that's a strawman, I only talked about linebreaks, not about paragraphs. :-) We definitely should not merge all paragraphs automatically. The same applies to indentation. But precisely to make these elements visible, I think it is important that we do not intermix line breaks (for text composition) with paragraphs (semantic units)! We already have too many comments in the image where I often wonder "is this a new thought or did the author just try to keep the lines short?".
I hope you will agree that the following two texts are semantically identical? Then they should not be encoded differently in the source code of a method:
[cid:9866d517-72b6-4288-9a60-4d1e3f83a129]
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Stéphane Rollandin lecteur@zogotounga.net Gesendet: Montag, 4. April 2022 16:43:57 An: squeak-dev@lists.squeakfoundation.org Betreff: Re: [squeak-dev] Manual line breaks in code
I feel reminded of some recent discussions about pretty-printing. Some people apparently want to control every detail of the appearance of their source code (line-breaking, text composition etc.),
I would be one of these people, but I would say it otherwise:
when I layout my code, and my comments, I am writing for another human being (most probably myself in the future). And when I read source code, and comments therein, I read what another human being has written.
Indentation, line breaks, etc all convey some meaning (otherwise we would not even bother about formatting in the first place).
To assume that an algorithm can properly "pretty-print" a hunman output intended to another human, we must assume that nothing is lost in the process.
Now if "details" did not matter, I could have said:
I would be one of these people, but I would say it otherwise: when I layout my code, and my comments, I am writing for another human being (most probably myself in the future). And when I read source code, and comments therein, I read what another human being has written. Indentation, line breaks, etc all convey some meaning (otherwise we would not even bother about formatting in the first place). To assume that an algorithm can properly "pretty-print" a hunman output intended to another human, we must assume that nothing is lost in the process. Or maybe I could have said: I would be one of these people, but I would say it otherwise: when I layout my code, and my comments, I am writing for another human being (most probably myself in the future). And when I read source code, and comments therein, I read what another human being has written. Indentation, line breaks, etc all convey some meaning (otherwise we would not even bother about formatting in the first place). To assume that an algorithm can properly "pretty-print" a hunman output intended to another human, we must assume that nothing is lost in the process.
But to me, these details matter.
Stef
Hi
On 4. May 2022, at 20:27, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:
Hi Stef,
that's a strawman, I only talked about linebreaks, not about paragraphs. :-) We definitely should not merge all paragraphs automatically. The same applies to indentation. But precisely to make these elements visible, I think it is important that we do not intermix line breaks (for text composition) with paragraphs (semantic units)! We already have too many comments in the image where I often wonder "is this a new thought or did the author just try to keep the lines short?".
I hope you will agree that the following two texts are semantically identical? Then they should not be encoded differently in the source code of a method:
They should, for me. Also, I never wish to read the second :D -t
<pastedImage.png>
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Stéphane Rollandin lecteur@zogotounga.net Gesendet: Montag, 4. April 2022 16:43:57 An: squeak-dev@lists.squeakfoundation.org Betreff: Re: [squeak-dev] Manual line breaks in code
I feel reminded of some recent discussions about pretty-printing. Some people apparently want to control every detail of the appearance of their source code (line-breaking, text composition etc.),
I would be one of these people, but I would say it otherwise:
when I layout my code, and my comments, I am writing for another human being (most probably myself in the future). And when I read source code, and comments therein, I read what another human being has written.
Indentation, line breaks, etc all convey some meaning (otherwise we would not even bother about formatting in the first place).
To assume that an algorithm can properly "pretty-print" a hunman output intended to another human, we must assume that nothing is lost in the process.
Now if "details" did not matter, I could have said:
I would be one of these people, but I would say it otherwise: when I layout my code, and my comments, I am writing for another human being (most probably myself in the future). And when I read source code, and comments therein, I read what another human being has written. Indentation, line breaks, etc all convey some meaning (otherwise we would not even bother about formatting in the first place). To assume that an algorithm can properly "pretty-print" a hunman output intended to another human, we must assume that nothing is lost in the process. Or maybe I could have said: I would be one of these people, but I would say it otherwise: when I layout my code, and my comments, I am writing for another human being (most probably myself in the future). And when I read source code, and comments therein, I read what another human being has written. Indentation, line breaks, etc all convey some meaning (otherwise we would not even bother about formatting in the first place). To assume that an algorithm can properly "pretty-print" a hunman output intended to another human, we must assume that nothing is lost in the process.
But to me, these details matter.
Stef
Hi Jaromir,
do I understand correctly that only think in Squeak's text composition you are missing are hanging indents? I can't imagine that it should be overly complicated to implement them. But this might be a matter of taste - especially in code with many indentations, I am happy that to exploit the full width of the viewport for longer comments.
My proposal is to not include the documentation in a comment at all.
I?m not sure how to understand that; I?ve recently worked on a few methods (#terminate etc.) where I felt the need to add as much comment text as possible? even more comment than code :) Would that be considered a ?documentation?? Where else to put it?
I think Lauren was just referring to the representation of the method comment via a separate textbox. However, for myself, this would not be simple & minimalistic enough, I guess. ?
Best, Christoph
--- Sent from Squeak Inbox Talk
On 2022-04-01T20:30:33+00:00, mail@jaromir.net wrote:
Hi Christoph, Tobias, Lauren, all
A comment like this is totally fine to me:
terminate "Stop the receiver forever. Run all unwind contexts (#ensure:/#ifCurtailed: blocks) on the stack, even if they are currently in progress. If already active unwind contexts should not be continued, send #terminateAggressively instead. NOTE THAT bla bla bla!"I dare to disagree here ? this looks distracting to me. Dolphin solved this by indenting long lines to make them into a tidy indented paragraph.
But not this:
terminate "Stop the receiver forever. Run all unwind contexts (#ensure:/#ifCurtailed: blocks) on the stack, even if they are currently in progress. If already active unwind contexts should not be continued, send #terminateAggressively instead. NOTE THAT bla bla bla!"Unless Squeak somehow employs a reasonable indentation I personally prefer this way ? especially for comments inside the indented code ? long lines break indentation and the resulting look is unfortunate; I?m trying to avoid long comments but sometimes a longer comment just feels appropriate.
I put linebreaks there because I want them exactly there :)
Yes, I do that too? to manually enforce indentation, really.
I?ve noticed VW are struggling with the same dilemma too :)
My proposal is to not include the documentation in a comment at all.
I?m not sure how to understand that; I?ve recently worked on a few methods (#terminate etc.) where I felt the need to add as much comment text as possible? even more comment than code :) Would that be considered a ?documentation?? Where else to put it?
Thanks,
--
Jaromír Matas
mail at jaromir.net
From: christoph.thiede at student.hpi.uni-potsdam.de<mailto:christoph.thiede at student.hpi.uni-potsdam.de> Sent: Friday, April 1, 2022 18:35 To: squeak-dev at lists.squeakfoundation.org<mailto:squeak-dev at lists.squeakfoundation.org> Subject: Re: [squeak-dev] Manual line breaks in code
Hi Tobias, Hi Lauren,
I put linebreaks there because I want them exactly there :)
But then you are talking more about paragraphs rather than linebreaks, aren't you? :-)
A comment like this is totally fine to me:
terminate "Stop the receiver forever. Run all unwind contexts (#ensure:/#ifCurtailed: blocks) on the stack, even if they are currently in progress. If already active unwind contexts should not be continued, send #terminateAggressively instead. NOTE THAT bla bla bla!"But not this:
terminate "Stop the receiver forever. Run all unwind contexts (#ensure:/#ifCurtailed: blocks) on the stack, even if they are currently in progress. If already active unwind contexts should not be continued, send #terminateAggressively instead. NOTE THAT bla bla bla!"In the second example, we would just stupidically do the work of the text composer. Similar to the "tabs vs spaces" debate, spaces/manual linebreaks prescribe the appearance of the code/text, whereas tabs/automatic line-breaking leave this decision to the tooling of the reader or author. If I resize my browser window, I would like its contents to be re-layouted as flexibly as possible.
Even worse, manual linebreaks blur the differences between semantically distinct paragraphs and composition-specific linebreaks.
@Lauren:
My proposal is to not include the documentation in a comment at all.
I think you are neglecting comments in the midst of any method, which occur pretty frequently in Squeak and are an important part of Smalltalk programming IMHO. :)
Best, Christoph
Sent from Squeak Inbox Talkhttps://github.com/hpi-swa-lab/squeak-inbox-talk
On 2022-04-01T16:06:01+00:00, drurowin at gmail.com wrote:
Hi Christoph, Marcel, Tobias,
My proposal is to not include the documentation in a comment at all.
Add a dedicated text box to the browser for the comment and treat method comments like class comments, but then display both code and documentation simultaneously side by side. Then there could be completely different rules for formatting text from formatting code. I want each text line to be narrow... but I want each code line to be able to be wide to take advantage of indentation.
On 4/1/22 11:42, christoph.thiede at student.hpi.uni-potsdam.de wrote:
How about email's format=flowed?
A problem with this could be that some systems do not preserve trailing spaces. For instance, they do not appear in the mailing list archive. :-)
Unrelated, I checked my copy of the sent mail and it looks like my client stripped the trailing spaces when it got sent to prepare it for the ml archive.
This might be a problem with the inlined diffs that get sent out when people save new versions, but I still think it's the least intrusive option and doesn't require any special non-space-bar spaces. It wouldn't affect code samples in the comments, and you could detect paragraphs all on one literal line by the period-return-return and period-endOfComment patterns.
If you press return you get a normal line break (for people like Tobias and myself, who put in line breaks because they're supposed to be there), and if you hit the space bar right before that it signals the comment formatting engine to use the user's preference to change the line widths.
Hi Christoph,
do I understand correctly that only think in Squeak's text composition you are missing are hanging indents?
Yes, take a look at Dolphin’s simple solution in the enclosed screenshots; the second picture shows what Dolphin does when you resize the window: it simply indents the comment based on the indentation of the line the comment starts on… Actually, it analogically indents the code lines as well so the result looks neat and consistent.
Best,
--
Jaromír Matas
+420 777 492 777 mail@jaromir.net
From: christoph.thiede@student.hpi.uni-potsdam.demailto:christoph.thiede@student.hpi.uni-potsdam.de Sent: Friday, April 1, 2022 23:42 To: squeak-dev@lists.squeakfoundation.orgmailto:squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Manual line breaks in code
Hi Jaromir,
do I understand correctly that only think in Squeak's text composition you are missing are hanging indents? I can't imagine that it should be overly complicated to implement them. But this might be a matter of taste - especially in code with many indentations, I am happy that to exploit the full width of the viewport for longer comments.
My proposal is to not include the documentation in a comment at all.
I?m not sure how to understand that; I?ve recently worked on a few methods (#terminate etc.) where I felt the need to add as much comment text as possible? even more comment than code :) Would that be considered a ?documentation?? Where else to put it?
I think Lauren was just referring to the representation of the method comment via a separate textbox. However, for myself, this would not be simple & minimalistic enough, I guess. ?
Best, Christoph
--- Sent from Squeak Inbox Talkhttps://github.com/hpi-swa-lab/squeak-inbox-talk
On 2022-04-01T20:30:33+00:00, mail@jaromir.net wrote:
Hi Christoph, Tobias, Lauren, all
A comment like this is totally fine to me:
terminate "Stop the receiver forever. Run all unwind contexts (#ensure:/#ifCurtailed: blocks) on the stack, even if they are currently in progress. If already active unwind contexts should not be continued, send #terminateAggressively instead. NOTE THAT bla bla bla!"
I dare to disagree here ? this looks distracting to me. Dolphin solved this by indenting long lines to make them into a tidy indented paragraph.
But not this:
terminate "Stop the receiver forever. Run all unwind contexts (#ensure:/#ifCurtailed: blocks) on the stack, even if they are currently in progress. If already active unwind contexts should not be continued, send #terminateAggressively instead. NOTE THAT bla bla bla!"
Unless Squeak somehow employs a reasonable indentation I personally prefer this way ? especially for comments inside the indented code ? long lines break indentation and the resulting look is unfortunate; I?m trying to avoid long comments but sometimes a longer comment just feels appropriate.
I put linebreaks there because I want them exactly there :)
Yes, I do that too? to manually enforce indentation, really.
I?ve noticed VW are struggling with the same dilemma too :)
My proposal is to not include the documentation in a comment at all.
I?m not sure how to understand that; I?ve recently worked on a few methods (#terminate etc.) where I felt the need to add as much comment text as possible? even more comment than code :) Would that be considered a ?documentation?? Where else to put it?
Thanks,
--
Jaromír Matas
mail at jaromir.net
From: christoph.thiede at student.hpi.uni-potsdam.de<mailto:christoph.thiede at student.hpi.uni-potsdam.de> Sent: Friday, April 1, 2022 18:35 To: squeak-dev at lists.squeakfoundation.org<mailto:squeak-dev at lists.squeakfoundation.org> Subject: Re: [squeak-dev] Manual line breaks in code
Hi Tobias, Hi Lauren,
I put linebreaks there because I want them exactly there :)
But then you are talking more about paragraphs rather than linebreaks, aren't you? :-)
A comment like this is totally fine to me:
terminate "Stop the receiver forever. Run all unwind contexts (#ensure:/#ifCurtailed: blocks) on the stack, even if they are currently in progress. If already active unwind contexts should not be continued, send #terminateAggressively instead. NOTE THAT bla bla bla!"
But not this:
terminate "Stop the receiver forever. Run all unwind contexts (#ensure:/#ifCurtailed: blocks) on the stack, even if they are currently in progress. If already active unwind contexts should not be continued, send #terminateAggressively instead. NOTE THAT bla bla bla!"
In the second example, we would just stupidically do the work of the text composer. Similar to the "tabs vs spaces" debate, spaces/manual linebreaks prescribe the appearance of the code/text, whereas tabs/automatic line-breaking leave this decision to the tooling of the reader or author. If I resize my browser window, I would like its contents to be re-layouted as flexibly as possible.
Even worse, manual linebreaks blur the differences between semantically distinct paragraphs and composition-specific linebreaks.
@Lauren:
My proposal is to not include the documentation in a comment at all.
I think you are neglecting comments in the midst of any method, which occur pretty frequently in Squeak and are an important part of Smalltalk programming IMHO. :)
Best, Christoph
Sent from Squeak Inbox Talkhttps://github.com/hpi-swa-lab/squeak-inbox-talk
On 2022-04-01T16:06:01+00:00, drurowin at gmail.com wrote:
Hi Christoph, Marcel, Tobias,
My proposal is to not include the documentation in a comment at all.
Add a dedicated text box to the browser for the comment and treat method comments like class comments, but then display both code and documentation simultaneously side by side. Then there could be completely different rules for formatting text from formatting code. I want each text line to be narrow... but I want each code line to be able to be wide to take advantage of indentation.
On 4/1/22 11:42, christoph.thiede at student.hpi.uni-potsdam.de wrote:
How about email's format=flowed?
A problem with this could be that some systems do not preserve trailing spaces. For instance, they do not appear in the mailing list archive. :-)
Unrelated, I checked my copy of the sent mail and it looks like my client stripped the trailing spaces when it got sent to prepare it for the ml archive.
This might be a problem with the inlined diffs that get sent out when people save new versions, but I still think it's the least intrusive option and doesn't require any special non-space-bar spaces. It wouldn't affect code samples in the comments, and you could detect paragraphs all on one literal line by the period-return-return and period-endOfComment patterns.
If you press return you get a normal line break (for people like Tobias and myself, who put in line breaks because they're supposed to be there), and if you hit the space bar right before that it signals the comment formatting engine to use the user's preference to change the line widths.
Hi
On 1. Apr 2022, at 18:35, christoph.thiede@student.hpi.uni-potsdam.de wrote:
Hi Tobias, Hi Lauren,
I put linebreaks there because I want them exactly there :)
But then you are talking more about paragraphs rather than linebreaks, aren't you? :-)
A comment like this is totally fine to me:
terminate "Stop the receiver forever. Run all unwind contexts (#ensure:/#ifCurtailed: blocks) on the stack, even if they are currently in progress. If already active unwind contexts should not be continued, send #terminateAggressively instead. NOTE THAT bla bla bla!"But not this:
terminate "Stop the receiver forever. Run all unwind contexts (#ensure:/#ifCurtailed: blocks) on the stack, even if they are currently in progress. If already active unwind contexts should not be continued, send #terminateAggressively instead. NOTE THAT bla bla bla!"
For me it is the opposite. I am really annoyed by the first kind of comments. It just does not have a readable shape. -T
In the second example, we would just stupidically do the work of the text composer. Similar to the "tabs vs spaces" debate, spaces/manual linebreaks prescribe the appearance of the code/text, whereas tabs/automatic line-breaking leave this decision to the tooling of the reader or author. If I resize my browser window, I would like its contents to be re-layouted as flexibly as possible.
Even worse, manual linebreaks blur the differences between semantically distinct paragraphs and composition-specific linebreaks.
@Lauren:
My proposal is to not include the documentation in a comment at all.
I think you are neglecting comments in the midst of any method, which occur pretty frequently in Squeak and are an important part of Smalltalk programming IMHO. :)
Best, Christoph
Sent from Squeak Inbox Talk
On 2022-04-01T16:06:01+00:00, drurowin@gmail.com wrote:
Hi Christoph, Marcel, Tobias,
My proposal is to not include the documentation in a comment at all.
Add a dedicated text box to the browser for the comment and treat method comments like class comments, but then display both code and documentation simultaneously side by side. Then there could be completely different rules for formatting text from formatting code. I want each text line to be narrow... but I want each code line to be able to be wide to take advantage of indentation.
On 4/1/22 11:42, christoph.thiede at student.hpi.uni-potsdam.de wrote:
How about email's format=flowed?
A problem with this could be that some systems do not preserve trailing spaces. For instance, they do not appear in the mailing list archive. :-)
Unrelated, I checked my copy of the sent mail and it looks like my client stripped the trailing spaces when it got sent to prepare it for the ml archive.
This might be a problem with the inlined diffs that get sent out when people save new versions, but I still think it's the least intrusive option and doesn't require any special non-space-bar spaces. It wouldn't affect code samples in the comments, and you could detect paragraphs all on one literal line by the period-return-return and period-endOfComment patterns.
If you press return you get a normal line break (for people like Tobias and myself, who put in line breaks because they're supposed to be there), and if you hit the space bar right before that it signals the comment formatting engine to use the user's preference to change the line widths.
Hi Christoph --
I'm not yet convinced. :-) In almost all situations, I do not see any other sense in manual line breaks in comments than working around the absence of a proper line-breaking mechanism. There is (or should not be) any need for this nowadays.
First we shape our tools. And then our tools shape us. :-)
One way is not better or worse then the other way, especially, if you notice that people cannot agree on a common way but that more complex forces seem to be at play.
Someone likes to resize windows; another one may not. Someone likes to insert hard line breaks; another one may not. Someone knows how to configure tools; another one may not.
We should learn to respect and accept each others preferences. To not annoy one another more than necessary. :-D
Best, Marcel Am 01.04.2022 13:43:14 schrieb christoph.thiede@student.hpi.uni-potsdam.de christoph.thiede@student.hpi.uni-potsdam.de: Hi Marcel, Hi Lauren,
I know that some of us tend to remove manual line breaks in such longer comments but we might want to stop doing that if it is easy the retain the original format.
I'm not yet convinced. :-) In almost all situations, I do not see any other sense in manual line breaks in comments than working around the absence of a proper line-breaking mechanism. There is (or should not be) any need for this nowadays. If we want to reduce noise on the mailing list, I would rather consider this a tooling problem.
That said, it would be nice to have a feature in SmalltalkEditor or TextEditor that converts the soft line breaks of the current text selection into hard line breaks and vice versa.
My first impression of this proposal would be that it would complicate understanding what's actually in a text vs how the text is displayed ... too many abstractions ...
Anyway, thanks for the pointers to the preferences!
How about email's format=flowed?
A problem with this could be that some systems do not preserve trailing spaces. For instance, they do not appear in the mailing list archive. :-)
Best, Christoph
--- Sent from Squeak Inbox Talk [https://github.com/hpi-swa-lab/squeak-inbox-talk]
On 2022-03-29T10:57:30-06:00, drurowin@gmail.com wrote:
Hi Marcel, Christoph,
On Tue, Mar 29, 2022, 01:58 Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
Hi Christoph --
Thanks. Treat this as a piece of pre-formatted document. It is actually like source code where authors sometimes want to pre-format the linebreaks of a longer comment to not have to fiddle around with window resizing.
I know that some of us tend to remove manual line breaks in such longer comments but we might want to stop doing that if it is easy the retain the original format.
For longer comments without extra line breaks, the following preference can help programmers that have troubles reading other author's source code:
PluggableTextMorph softLineWrap: false. PluggableTextMorph visualWrapBorder: true. PluggableTextMorph softLineWrapAtVisualWrapBorder: true. PluggableTextMorph visualWrapBorderLimit: 80.
That said, it would be nice to have a feature in SmalltalkEditor or TextEditor that converts the soft line breaks of the current text selection into hard line breaks and vice versa.
Then we can more easily preserve both styles of formatting longer commentary. :-)
How about email's format=flowed? It uses a trailing space to indicate the next line can be merged and wrapped according to the viewer's preferences. We could visually mark that special end-of-line space in source mode so it's obvious, but then process it in pretty print and documentation.
This line would be merged with the rest. But this would be forced to a new one. Select the text to see the trailing blanks.
squeak-dev@lists.squeakfoundation.org
-
christoph.thiede＠student.hpi.uni-potsdam.de -
commits＠source.squeak.org -
David T. Lewis -
Jakob Reschke -
Jaromir Matas -
Lauren P -
Lauren Pullen
-
Marcel Taeumel -
Stéphane Rollandin -
Thiede, Christoph
-
tim Rowledge -
Tobias Pape