Chris Muller uploaded a new version of Compiler to project The Inbox: http://source.squeak.org/inbox/Compiler-cmm.480.mcz
==================== Summary ====================
Name: Compiler-cmm.480 Author: cmm Time: 13 July 2022, 3:58:02.487109 pm UUID: 0af0343b-cf23-427a-8bff-1b45941699dc Ancestors: Compiler-eem.479
Preserve hand-crafted formatting of comments.
=============== Diff against Compiler-eem.479 ===============
Item was changed: ----- Method: ParseNode>>printSingleComment:on:indent: (in category 'private') ----- printSingleComment: aString on: aStream indent: indent + "Preserve hand-crafted formatting of comments." + aStream nextPutAll: aString! - "Print the comment string, assuming it has been indented indent tabs. - Break the string at word breaks, given the widths in the default - font, at 450 points." - - | readStream word position lineBreak font wordWidth tabWidth spaceWidth lastChar | - readStream := ReadStream on: aString. - font := TextStyle default defaultFont. - tabWidth := TextStyle default tabWidth. - spaceWidth := font widthOf: Character space. - position := indent * tabWidth. - lineBreak := 450. - [readStream atEnd] - whileFalse: - [word := self nextWordFrom: readStream setCharacter: [:lc | lastChar := lc]. - wordWidth := word inject: 0 into: [:width :char | width + (font widthOf: char)]. - position := position + wordWidth. - position > lineBreak - ifTrue: - [aStream skip: -1; crtab: indent. - position := indent * tabWidth + wordWidth + spaceWidth. - lastChar = Character cr - ifTrue: [[readStream peekFor: Character tab] whileTrue]. - word isEmpty ifFalse: [aStream nextPutAll: word; space]] - ifFalse: - [aStream nextPutAll: word. - readStream atEnd - ifFalse: - [position := position + spaceWidth. - aStream space]. - lastChar = Character cr - ifTrue: - [aStream skip: -1; crtab: indent. - position := indent * tabWidth. - [readStream peekFor: Character tab] whileTrue]]]!
Hi all --
I have no objection here. Actually, a strong +1 because the current form is incompatible with scale factor larger than 100% and thus high-dpi.
If one would reformat comments, I would strongly suggest to NOT define line breaks via pixels but only based on a sane lines-per-character default. Maybe -- and only because Squeak uses proportional fonts by default -- use the text-layout algorithm to figure out the breaks. See Text >> #withNoLineLongerThan: so learn more about how this could work for the pretty-printer as well.
Best, Marcel Am 13.07.2022 22:58:12 schrieb commits@source.squeak.org commits@source.squeak.org: Chris Muller uploaded a new version of Compiler to project The Inbox: http://source.squeak.org/inbox/Compiler-cmm.480.mcz
==================== Summary ====================
Name: Compiler-cmm.480 Author: cmm Time: 13 July 2022, 3:58:02.487109 pm UUID: 0af0343b-cf23-427a-8bff-1b45941699dc Ancestors: Compiler-eem.479
Preserve hand-crafted formatting of comments.
=============== Diff against Compiler-eem.479 ===============
Item was changed: ----- Method: ParseNode>>printSingleComment:on:indent: (in category 'private') ----- printSingleComment: aString on: aStream indent: indent + "Preserve hand-crafted formatting of comments." + aStream nextPutAll: aString! - "Print the comment string, assuming it has been indented indent tabs. - Break the string at word breaks, given the widths in the default - font, at 450 points." - - | readStream word position lineBreak font wordWidth tabWidth spaceWidth lastChar | - readStream := ReadStream on: aString. - font := TextStyle default defaultFont. - tabWidth := TextStyle default tabWidth. - spaceWidth := font widthOf: Character space. - position := indent * tabWidth. - lineBreak := 450. - [readStream atEnd] - whileFalse: - [word := self nextWordFrom: readStream setCharacter: [:lc | lastChar := lc]. - wordWidth := word inject: 0 into: [:width :char | width + (font widthOf: char)]. - position := position + wordWidth. - position > lineBreak - ifTrue: - [aStream skip: -1; crtab: indent. - position := indent * tabWidth + wordWidth + spaceWidth. - lastChar = Character cr - ifTrue: [[readStream peekFor: Character tab] whileTrue]. - word isEmpty ifFalse: [aStream nextPutAll: word; space]] - ifFalse: - [aStream nextPutAll: word. - readStream atEnd - ifFalse: - [position := position + spaceWidth. - aStream space]. - lastChar = Character cr - ifTrue: - [aStream skip: -1; crtab: indent. - position := indent * tabWidth. - [readStream peekFor: Character tab] whileTrue]]]!
On 2022-07-13, at 11:35 PM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
If one would reformat comments, I would strongly suggest to NOT define line breaks via pixels but only based on a sane lines-per-character default. Maybe -- and only because Squeak uses proportional fonts by default -- use the text-layout algorithm to figure out the breaks.
I claim it should just be the width of the frame you are rendering the text into.
A luxury option would be to try to keep the left edge aligned with the starting location of the comment. Obviously there are edge case where the right edge is so close that we'd have to simply abandon hope, and so on.
To try to illustrate - self doSomethingOrOther + foo blather "a comment that goes on a bit about nothing very useful but drifts on and on and on like a speech by a particularly boring emeritus professor of classics after a booze fuelled Old Etonian conspiracy meeting"
... isn't terribly readable (ignoring the quality of the content!). If we could make it wrap more helpfully it might appear as self doSomethingOrOther + foo blather "a comment that goes on a bit about nothing very useful but drifts on and on and on like a speech by a particularly boring emeritus professor of classics after a booze fuelled Old Etonian conspiracy meeting"
.. .which I suggest looks a lot better. If your rendering frame is rather narrower it might end up self doSomethingOrOther + foo blather "a comment that goes on a bit about nothing very useful but drifts on and on and on like a speech by a particularly boring emeritus professor of classics after a booze fuelled Old Etonian conspiracy meeting" Maybe if the right edge is closer than perhaps 20 ems one might wrap to the beginning of the line of code + a tab? self doSomethingOrOther + foo blather "a comment that goes on a bit about nothing very useful but drifts on and on and on like a speech by a particularly boring emeritus professor of classics after a booze fuelled Old Etonian conspiracy meeting"
Along with having Shout use italics for comments that would still be pretty readable.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oyster (n.), a person who sprinkles his conversation with Yiddishisms.
75em may also be a good limit, now that Number even understands such a selector. https://baymard.com/blog/line-length-readability
But seeing Tim's examples: before we start tweaking the indentation of comments by the pretty printer, which would have it insert tabs or spaces or anything else, better implement that proposal to display comment lines left-aligned with the opening ", without requiring indentation characters in the source text. Remember that other thread about whether or not to have line breaks in comments? Somebody posted a screenshot from Dolphin Smalltalk that shows what I am referring to.
To leave the comments untouched by the pretty-printer seems reasonable to me for now.
Am Do., 14. Juli 2022 um 19:34 Uhr schrieb tim Rowledge tim@rowledge.org:
On 2022-07-13, at 11:35 PM, Marcel Taeumel marcel.taeumel@hpi.de
wrote:
If one would reformat comments, I would strongly suggest to NOT define
line breaks via pixels but only based on a sane lines-per-character default. Maybe -- and only because Squeak uses proportional fonts by default -- use the text-layout algorithm to figure out the breaks.
I claim it should just be the width of the frame you are rendering the text into.
A luxury option would be to try to keep the left edge aligned with the starting location of the comment. Obviously there are edge case where the right edge is so close that we'd have to simply abandon hope, and so on.
To try to illustrate - self doSomethingOrOther + foo blather "a comment that goes on a bit about nothing very useful but drifts on and on and on like a speech by a particularly boring emeritus professor of classics after a booze fuelled Old Etonian conspiracy meeting"
... isn't terribly readable (ignoring the quality of the content!). If we could make it wrap more helpfully it might appear as self doSomethingOrOther + foo blather "a comment that goes on a bit about nothing very useful but drifts on and on and on like a speech by a particularly boring emeritus professor of classics after a booze fuelled Old Etonian conspiracy meeting"
.. .which I suggest looks a lot better. If your rendering frame is rather narrower it might end up self doSomethingOrOther + foo blather "a comment that goes on a bit about nothing very useful but drifts on and on and on like a speech by a particularly boring emeritus professor of classics after a booze fuelled Old Etonian conspiracy meeting" Maybe if the right edge is closer than perhaps 20 ems one might wrap to the beginning of the line of code + a tab? self doSomethingOrOther + foo blather "a comment that goes on a bit about nothing very useful but drifts on and on and on like a speech by a particularly boring emeritus professor of classics after a booze fuelled Old Etonian conspiracy meeting"
Along with having Shout use italics for comments that would still be pretty readable.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oyster (n.), a person who sprinkles his conversation with Yiddishisms.
On 2022-07-14, at 10:48 AM, Jakob Reschke jakres+squeak@gmail.com wrote:
75em may also be a good limit, now that Number even understands such a selector. https://baymard.com/blog/line-length-readability
That's an excellent point; extra-long lines are really annoying to read in general.
But seeing Tim's examples: before we start tweaking the indentation of comments by the pretty printer, which would have it insert tabs or spaces or anything else, better implement that proposal to display comment lines left-aligned with the opening ", without requiring indentation characters in the source text. Remember that other thread about whether or not to have line breaks in comments? Somebody posted a screenshot from Dolphin Smalltalk that shows what I am referring to.
To leave the comments untouched by the pretty-printer seems reasonable to me for now.
Oh, I'm not wanting to have any tabs or spaces inserted - I want the formatting to be live and use the left indent. Shout does all that work to colour (etc) the text so why not use the fact that it detects comments.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- His seat back is not in the full upright and locked position.
75em may also be a good limit, now that Number even understands such a selector.
Nope. We need something independent from a scale factor and thus the default font size as pretty-printed format can be checked in. Better use "66 characters", not 75em. No rendering/font properties. For multi-line comments, use the line-break algorithm as in Text >> #withNoLineLongerThan:.
Please read the commentary in TextStyle >> #compositionWidthForNumChars
Best, Marcel Am 14.07.2022 19:55:04 schrieb tim Rowledge tim@rowledge.org:
On 2022-07-14, at 10:48 AM, Jakob Reschke wrote:
75em may also be a good limit, now that Number even understands such a selector. https://baymard.com/blog/line-length-readability
That's an excellent point; extra-long lines are really annoying to read in general.
But seeing Tim's examples: before we start tweaking the indentation of comments by the pretty printer, which would have it insert tabs or spaces or anything else, better implement that proposal to display comment lines left-aligned with the opening ", without requiring indentation characters in the source text. Remember that other thread about whether or not to have line breaks in comments? Somebody posted a screenshot from Dolphin Smalltalk that shows what I am referring to.
To leave the comments untouched by the pretty-printer seems reasonable to me for now.
Oh, I'm not wanting to have any tabs or spaces inserted - I want the formatting to be live and use the left indent. Shout does all that work to colour (etc) the text so why not use the fact that it detects comments.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- His seat back is not in the full upright and locked position.
If the research has already been done, then there is no need for guessing and further suggestions. All the better :-)
I thought that the em would actually be a unit to get something like x characters in width, using M as the particular character as a basis.
Am Di., 19. Juli 2022 um 14:21 Uhr schrieb Marcel Taeumel < marcel.taeumel@hpi.de>:
75em may also be a good limit, now that Number even understands such a
selector.
Nope. We need something independent from a scale factor and thus the default font size as pretty-printed format can be checked in. Better use "66 characters", not 75em. No rendering/font properties. For multi-line comments, use the line-break algorithm as in Text >> #withNoLineLongerThan:.
Please read the commentary in TextStyle >> #compositionWidthForNumChars
Best, Marcel
Am 14.07.2022 19:55:04 schrieb tim Rowledge tim@rowledge.org:
On 2022-07-14, at 10:48 AM, Jakob Reschke wrote:
75em may also be a good limit, now that Number even understands such a
selector.
That's an excellent point; extra-long lines are really annoying to read in general.
But seeing Tim's examples: before we start tweaking the indentation of
comments by the pretty printer, which would have it insert tabs or spaces or anything else, better implement that proposal to display comment lines left-aligned with the opening ", without requiring indentation characters in the source text. Remember that other thread about whether or not to have line breaks in comments? Somebody posted a screenshot from Dolphin Smalltalk that shows what I am referring to.
To leave the comments untouched by the pretty-printer seems reasonable
to me for now.
Oh, I'm not wanting to have any tabs or spaces inserted - I want the formatting to be live and use the left indent. Shout does all that work to colour (etc) the text so why not use the fact that it detects comments.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- His seat back is not in the full upright and locked position.
I thought that the em would actually be a unit to get something like x characters in width, using M as the particular character as a basis.
Ah, right. Should work. Yet, I would not write a new text composition algorithm but re-use our existing one. And that one is based on either "type factor " or "num chars".
Best, Marcel Am 19.07.2022 14:37:40 schrieb Jakob Reschke jakres+squeak@gmail.com: If the research has already been done, then there is no need for guessing and further suggestions. All the better :-)
I thought that the em would actually be a unit to get something like x characters in width, using M as the particular character as a basis.
Am Di., 19. Juli 2022 um 14:21 Uhr schrieb Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]>:
75em may also be a good limit, now that Number even understands such a selector.
Nope. We need something independent from a scale factor and thus the default font size as pretty-printed format can be checked in. Better use "66 characters", not 75em. No rendering/font properties. For multi-line comments, use the line-break algorithm as in Text >> #withNoLineLongerThan:.
Please read the commentary in TextStyle >> #compositionWidthForNumChars
Best, Marcel Am 14.07.2022 19:55:04 schrieb tim Rowledge <tim@rowledge.org [mailto:tim@rowledge.org]>:
On 2022-07-14, at 10:48 AM, Jakob Reschke wrote:
75em may also be a good limit, now that Number even understands such a selector. https://baymard.com/blog/line-length-readability [https://baymard.com/blog/line-length-readability]
That's an excellent point; extra-long lines are really annoying to read in general.
But seeing Tim's examples: before we start tweaking the indentation of comments by the pretty printer, which would have it insert tabs or spaces or anything else, better implement that proposal to display comment lines left-aligned with the opening ", without requiring indentation characters in the source text. Remember that other thread about whether or not to have line breaks in comments? Somebody posted a screenshot from Dolphin Smalltalk that shows what I am referring to.
To leave the comments untouched by the pretty-printer seems reasonable to me for now.
Oh, I'm not wanting to have any tabs or spaces inserted - I want the formatting to be live and use the left indent. Shout does all that work to colour (etc) the text so why not use the fact that it detects comments.
tim -- tim Rowledge; tim@rowledge.org [mailto:tim@rowledge.org]; http://www.rowledge.org/tim [http://www.rowledge.org/tim] Useful random insult:- His seat back is not in the full upright and locked position.
Hi all, em is a typical unit used in latex. Since it's the largest latin letter in most fonts, 75 em means that we'll get at least 75 chars... Nicolas
Le mar. 19 juil. 2022 à 14:50, Marcel Taeumel marcel.taeumel@hpi.de a écrit :
I thought that the em would actually be a unit to get something like x characters in width, using M as the particular character as a basis.
Ah, right. Should work. Yet, I would not write a new text composition algorithm but re-use our existing one. And that one is based on either "type factor " or "num chars".
Best, Marcel
Am 19.07.2022 14:37:40 schrieb Jakob Reschke jakres+squeak@gmail.com: If the research has already been done, then there is no need for guessing and further suggestions. All the better :-)
I thought that the em would actually be a unit to get something like x characters in width, using M as the particular character as a basis.
Am Di., 19. Juli 2022 um 14:21 Uhr schrieb Marcel Taeumel < marcel.taeumel@hpi.de>:
75em may also be a good limit, now that Number even understands such a
selector.
Nope. We need something independent from a scale factor and thus the default font size as pretty-printed format can be checked in. Better use "66 characters", not 75em. No rendering/font properties. For multi-line comments, use the line-break algorithm as in Text >> #withNoLineLongerThan:.
Please read the commentary in TextStyle >> #compositionWidthForNumChars
Best, Marcel
Am 14.07.2022 19:55:04 schrieb tim Rowledge tim@rowledge.org:
On 2022-07-14, at 10:48 AM, Jakob Reschke wrote:
75em may also be a good limit, now that Number even understands such a
selector.
That's an excellent point; extra-long lines are really annoying to read in general.
But seeing Tim's examples: before we start tweaking the indentation of
comments by the pretty printer, which would have it insert tabs or spaces or anything else, better implement that proposal to display comment lines left-aligned with the opening ", without requiring indentation characters in the source text. Remember that other thread about whether or not to have line breaks in comments? Somebody posted a screenshot from Dolphin Smalltalk that shows what I am referring to.
To leave the comments untouched by the pretty-printer seems reasonable
to me for now.
Oh, I'm not wanting to have any tabs or spaces inserted - I want the formatting to be live and use the left indent. Shout does all that work to colour (etc) the text so why not use the fact that it detects comments.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- His seat back is not in the full upright and locked position.
Hi Nicolas --
[...] 75 em means that we'll get at least 75 chars...
Typography-wise, it just gets a little bit more complicated with non-monospaced fonts. For a prosa comment in Squeak's default proportional font, 75 em or 75 characters-per-line might be much on screen considering English text.
At the moment, we have preferences to play around with this: PluggableTextMorph softLineWrapAtVisualWrapBorder
PluggableTextMorph visualWrapBorder
PluggableTextMorph visualWrapBorderLimit
80 characters seem to be common for mono-spaced fonts. On average, that value also seems to work with Squeak's proportional Bitstream Vera Sans. It's a compromise. Tool windows are not a sheet of real paper.
Best, Marcel Am 19.07.2022 22:19:32 schrieb Nicolas Cellier nicolas.cellier.aka.nice@gmail.com: Hi all, em is a typical unit used in latex. Since it's the largest latin letter in most fonts, 75 em means that we'll get at least 75 chars... Nicolas
Le mar. 19 juil. 2022 à 14:50, Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> a écrit :
I thought that the em would actually be a unit to get something like x characters in width, using M as the particular character as a basis.
Ah, right. Should work. Yet, I would not write a new text composition algorithm but re-use our existing one. And that one is based on either "type factor " or "num chars".
Best, Marcel Am 19.07.2022 14:37:40 schrieb Jakob Reschke <jakres+squeak@gmail.com [mailto:jakres%2Bsqueak@gmail.com]>: If the research has already been done, then there is no need for guessing and further suggestions. All the better :-)
I thought that the em would actually be a unit to get something like x characters in width, using M as the particular character as a basis.
Am Di., 19. Juli 2022 um 14:21 Uhr schrieb Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]>:
75em may also be a good limit, now that Number even understands such a selector.
Nope. We need something independent from a scale factor and thus the default font size as pretty-printed format can be checked in. Better use "66 characters", not 75em. No rendering/font properties. For multi-line comments, use the line-break algorithm as in Text >> #withNoLineLongerThan:.
Please read the commentary in TextStyle >> #compositionWidthForNumChars
Best, Marcel Am 14.07.2022 19:55:04 schrieb tim Rowledge <tim@rowledge.org [mailto:tim@rowledge.org]>:
On 2022-07-14, at 10:48 AM, Jakob Reschke wrote:
75em may also be a good limit, now that Number even understands such a selector. https://baymard.com/blog/line-length-readability [https://baymard.com/blog/line-length-readability]
That's an excellent point; extra-long lines are really annoying to read in general.
But seeing Tim's examples: before we start tweaking the indentation of comments by the pretty printer, which would have it insert tabs or spaces or anything else, better implement that proposal to display comment lines left-aligned with the opening ", without requiring indentation characters in the source text. Remember that other thread about whether or not to have line breaks in comments? Somebody posted a screenshot from Dolphin Smalltalk that shows what I am referring to.
To leave the comments untouched by the pretty-printer seems reasonable to me for now.
Oh, I'm not wanting to have any tabs or spaces inserted - I want the formatting to be live and use the left indent. Shout does all that work to colour (etc) the text so why not use the fact that it detects comments.
tim -- tim Rowledge; tim@rowledge.org [mailto:tim@rowledge.org]; http://www.rowledge.org/tim [http://www.rowledge.org/tim] Useful random insult:- His seat back is not in the full upright and locked position.
Hi all -
See Compiler-mt.480 (Inbox) for an alternative solution.
Best, Marcel Am 20.07.2022 09:36:46 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Nicolas --
[...] 75 em means that we'll get at least 75 chars...
Typography-wise, it just gets a little bit more complicated with non-monospaced fonts. For a prosa comment in Squeak's default proportional font, 75 em or 75 characters-per-line might be much on screen considering English text.
At the moment, we have preferences to play around with this: PluggableTextMorph softLineWrapAtVisualWrapBorder
PluggableTextMorph visualWrapBorder
PluggableTextMorph visualWrapBorderLimit
80 characters seem to be common for mono-spaced fonts. On average, that value also seems to work with Squeak's proportional Bitstream Vera Sans. It's a compromise. Tool windows are not a sheet of real paper.
Best, Marcel Am 19.07.2022 22:19:32 schrieb Nicolas Cellier nicolas.cellier.aka.nice@gmail.com: Hi all, em is a typical unit used in latex. Since it's the largest latin letter in most fonts, 75 em means that we'll get at least 75 chars... Nicolas
Le mar. 19 juil. 2022 à 14:50, Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> a écrit :
I thought that the em would actually be a unit to get something like x characters in width, using M as the particular character as a basis.
Ah, right. Should work. Yet, I would not write a new text composition algorithm but re-use our existing one. And that one is based on either "type factor " or "num chars".
Best, Marcel Am 19.07.2022 14:37:40 schrieb Jakob Reschke <jakres+squeak@gmail.com [mailto:jakres%2Bsqueak@gmail.com]>: If the research has already been done, then there is no need for guessing and further suggestions. All the better :-)
I thought that the em would actually be a unit to get something like x characters in width, using M as the particular character as a basis.
Am Di., 19. Juli 2022 um 14:21 Uhr schrieb Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]>:
75em may also be a good limit, now that Number even understands such a selector.
Nope. We need something independent from a scale factor and thus the default font size as pretty-printed format can be checked in. Better use "66 characters", not 75em. No rendering/font properties. For multi-line comments, use the line-break algorithm as in Text >> #withNoLineLongerThan:.
Please read the commentary in TextStyle >> #compositionWidthForNumChars
Best, Marcel Am 14.07.2022 19:55:04 schrieb tim Rowledge <tim@rowledge.org [mailto:tim@rowledge.org]>:
On 2022-07-14, at 10:48 AM, Jakob Reschke wrote:
75em may also be a good limit, now that Number even understands such a selector. https://baymard.com/blog/line-length-readability [https://baymard.com/blog/line-length-readability]
That's an excellent point; extra-long lines are really annoying to read in general.
But seeing Tim's examples: before we start tweaking the indentation of comments by the pretty printer, which would have it insert tabs or spaces or anything else, better implement that proposal to display comment lines left-aligned with the opening ", without requiring indentation characters in the source text. Remember that other thread about whether or not to have line breaks in comments? Somebody posted a screenshot from Dolphin Smalltalk that shows what I am referring to.
To leave the comments untouched by the pretty-printer seems reasonable to me for now.
Oh, I'm not wanting to have any tabs or spaces inserted - I want the formatting to be live and use the left indent. Shout does all that work to colour (etc) the text so why not use the fact that it detects comments.
tim -- tim Rowledge; tim@rowledge.org [mailto:tim@rowledge.org]; http://www.rowledge.org/tim [http://www.rowledge.org/tim] Useful random insult:- His seat back is not in the full upright and locked position.
Compiler-cmm.480 is rooted in the idea that the format of comments is a human communication that fundamentally belongs to the author. I _really_ think Compiler-mt.480 is the wrong approach if the goal is aesthetically "pleasing" comments. I put that in quotes because it's your personal preference -- I myself very much dislike long comments to be indented because it prioritizes aesthetics over readability. When a comment is long enough to take more than one line, it's worth seeing its delineation of that section of code in the left margin.
If you prefer them to be indented, please make a Shout preference that dynamically formats comments into indented paragraphs. That solution ensures *every* width is a good width instead of trying to guess about it and, IMO, intruding terribly into the sovereignty of someone's hand-crafted comments because someone else prefers indentation. Plus, an arbitrary width makes comments even *harder* to whenever the width you're reading in is narrower than the arbitrary width decided by the formatter (see screenshot, I picked a random method).
[image: formatting-code-good-comment-bad.png]
Squeak can do so much better, *easily* even, Text has supported indentation for years and years!
Best, Chris
On Wed, Jul 20, 2022 at 2:50 AM Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi all -
See Compiler-mt.480 (Inbox) for an alternative solution.
Best, Marcel
Am 20.07.2022 09:36:46 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Nicolas --
[...] 75 em means that we'll get at least 75 chars...
Typography-wise, it just gets a little bit more complicated with non-monospaced fonts. For a prosa comment in Squeak's default proportional font, 75 em or 75 characters-per-line might be much on screen considering English text.
At the moment, we have preferences to play around with this: PluggableTextMorph softLineWrapAtVisualWrapBorder PluggableTextMorph visualWrapBorder PluggableTextMorph visualWrapBorderLimit
80 characters seem to be common for mono-spaced fonts. On average, that value also seems to work with Squeak's proportional Bitstream Vera Sans. It's a compromise. Tool windows are not a sheet of real paper.
Best, Marcel
Am 19.07.2022 22:19:32 schrieb Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>: Hi all, em is a typical unit used in latex. Since it's the largest latin letter in most fonts, 75 em means that we'll get at least 75 chars... Nicolas
Le mar. 19 juil. 2022 à 14:50, Marcel Taeumel marcel.taeumel@hpi.de a écrit :
I thought that the em would actually be a unit to get something like x characters in width, using M as the particular character as a basis.
Ah, right. Should work. Yet, I would not write a new text composition algorithm but re-use our existing one. And that one is based on either "type factor " or "num chars".
Best, Marcel
Am 19.07.2022 14:37:40 schrieb Jakob Reschke jakres+squeak@gmail.com: If the research has already been done, then there is no need for guessing and further suggestions. All the better :-)
I thought that the em would actually be a unit to get something like x characters in width, using M as the particular character as a basis.
Am Di., 19. Juli 2022 um 14:21 Uhr schrieb Marcel Taeumel < marcel.taeumel@hpi.de>:
75em may also be a good limit, now that Number even understands such a
selector.
Nope. We need something independent from a scale factor and thus the default font size as pretty-printed format can be checked in. Better use "66 characters", not 75em. No rendering/font properties. For multi-line comments, use the line-break algorithm as in Text >> #withNoLineLongerThan:.
Please read the commentary in TextStyle >> #compositionWidthForNumChars
Best, Marcel
Am 14.07.2022 19:55:04 schrieb tim Rowledge tim@rowledge.org:
On 2022-07-14, at 10:48 AM, Jakob Reschke wrote:
75em may also be a good limit, now that Number even understands such a
selector.
That's an excellent point; extra-long lines are really annoying to read in general.
But seeing Tim's examples: before we start tweaking the indentation of
comments by the pretty printer, which would have it insert tabs or spaces or anything else, better implement that proposal to display comment lines left-aligned with the opening ", without requiring indentation characters in the source text. Remember that other thread about whether or not to have line breaks in comments? Somebody posted a screenshot from Dolphin Smalltalk that shows what I am referring to.
To leave the comments untouched by the pretty-printer seems reasonable
to me for now.
Oh, I'm not wanting to have any tabs or spaces inserted - I want the formatting to be live and use the left indent. Shout does all that work to colour (etc) the text so why not use the fact that it detects comments.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- His seat back is not in the full upright and locked position.
Hmm... now this turns out to be another "soft vs. hard linebreaks" discussion? Interesting. Personally, I don't care whether Shout inserts hard linebreaks or relies on soft linebreaks when pretty-printing a piece of code. Yes, that could as well be a preference in Shout.
Best, Marcel Am 22.07.2022 00:45:47 schrieb Chris Muller asqueaker@gmail.com: Compiler-cmm.480 is rooted in the idea that the format of comments is a human communication that fundamentally belongs to the author. I _really_ think Compiler-mt.480 is the wrong approach if the goal is aesthetically "pleasing" comments. I put that in quotes because it's your personal preference -- I myself very much dislike long comments to be indented because it prioritizes aesthetics over readability. When a comment is long enough to take more than one line, it's worth seeing its delineation of that section of code in the left margin.
If you prefer them to be indented, please make a Shout preference that dynamically formats comments into indented paragraphs. That solution ensures every width is a good width instead of trying to guess about it and, IMO, intruding terribly into the sovereignty of someone's hand-crafted comments because someone else prefers indentation. Plus, an arbitrary width makes comments even harder to whenever the width you're reading in is narrower than the arbitrary width decided by the formatter (see screenshot, I picked a random method).
[formatting-code-good-comment-bad.png]
Squeak can do so much better, easily even, Text has supported indentation for years and years!
Best, Chris
On Wed, Jul 20, 2022 at 2:50 AM Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:
Hi all -
See Compiler-mt.480 (Inbox) for an alternative solution.
Best, Marcel Am 20.07.2022 09:36:46 schrieb Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]>: Hi Nicolas --
[...] 75 em means that we'll get at least 75 chars...
Typography-wise, it just gets a little bit more complicated with non-monospaced fonts. For a prosa comment in Squeak's default proportional font, 75 em or 75 characters-per-line might be much on screen considering English text.
At the moment, we have preferences to play around with this: PluggableTextMorph softLineWrapAtVisualWrapBorder
PluggableTextMorph visualWrapBorder
PluggableTextMorph visualWrapBorderLimit
80 characters seem to be common for mono-spaced fonts. On average, that value also seems to work with Squeak's proportional Bitstream Vera Sans. It's a compromise. Tool windows are not a sheet of real paper.
Best, Marcel Am 19.07.2022 22:19:32 schrieb Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com [mailto:nicolas.cellier.aka.nice@gmail.com]>: Hi all, em is a typical unit used in latex. Since it's the largest latin letter in most fonts, 75 em means that we'll get at least 75 chars... Nicolas
Le mar. 19 juil. 2022 à 14:50, Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> a écrit :
I thought that the em would actually be a unit to get something like x characters in width, using M as the particular character as a basis.
Ah, right. Should work. Yet, I would not write a new text composition algorithm but re-use our existing one. And that one is based on either "type factor " or "num chars".
Best, Marcel Am 19.07.2022 14:37:40 schrieb Jakob Reschke <jakres+squeak@gmail.com [mailto:jakres%2Bsqueak@gmail.com]>: If the research has already been done, then there is no need for guessing and further suggestions. All the better :-)
I thought that the em would actually be a unit to get something like x characters in width, using M as the particular character as a basis.
Am Di., 19. Juli 2022 um 14:21 Uhr schrieb Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]>:
75em may also be a good limit, now that Number even understands such a selector.
Nope. We need something independent from a scale factor and thus the default font size as pretty-printed format can be checked in. Better use "66 characters", not 75em. No rendering/font properties. For multi-line comments, use the line-break algorithm as in Text >> #withNoLineLongerThan:.
Please read the commentary in TextStyle >> #compositionWidthForNumChars
Best, Marcel Am 14.07.2022 19:55:04 schrieb tim Rowledge <tim@rowledge.org [mailto:tim@rowledge.org]>:
On 2022-07-14, at 10:48 AM, Jakob Reschke wrote:
75em may also be a good limit, now that Number even understands such a selector. https://baymard.com/blog/line-length-readability [https://baymard.com/blog/line-length-readability]
That's an excellent point; extra-long lines are really annoying to read in general.
But seeing Tim's examples: before we start tweaking the indentation of comments by the pretty printer, which would have it insert tabs or spaces or anything else, better implement that proposal to display comment lines left-aligned with the opening ", without requiring indentation characters in the source text. Remember that other thread about whether or not to have line breaks in comments? Somebody posted a screenshot from Dolphin Smalltalk that shows what I am referring to.
To leave the comments untouched by the pretty-printer seems reasonable to me for now.
Oh, I'm not wanting to have any tabs or spaces inserted - I want the formatting to be live and use the left indent. Shout does all that work to colour (etc) the text so why not use the fact that it detects comments.
tim -- tim Rowledge; tim@rowledge.org [mailto:tim@rowledge.org]; http://www.rowledge.org/tim [http://www.rowledge.org/tim] Useful random insult:- His seat back is not in the full upright and locked position.
On 2022-07-25, at 5:08 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hmm... now this turns out to be another "soft vs. hard linebreaks" discussion? Interesting. Personally, I don't care whether Shout inserts hard linebreaks or relies on soft linebreaks when pretty-printing a piece of code.
I'm fairly sure we don't want Shout (or anything else!) inserting any sort of break, or tab; it should be formatting the strings according to rules just like it colours them. when written to a .st or .changes file any comments etc should be just long strings with only CRs & tabs as inserted by the author. And if we got the auto-formatting working well they would probably be very rare.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim There can never be a computer language in which you cannot write a bad program.
Ah, right. So "leave it be" seems to be the only sensible option here... ________________________________ From: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org on behalf of tim Rowledge tim@rowledge.org Sent: Monday, July 25, 2022 6:53:46 PM To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] The Inbox: Compiler-cmm.480.mcz
On 2022-07-25, at 5:08 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hmm... now this turns out to be another "soft vs. hard linebreaks" discussion? Interesting. Personally, I don't care whether Shout inserts hard linebreaks or relies on soft linebreaks when pretty-printing a piece of code.
I'm fairly sure we don't want Shout (or anything else!) inserting any sort of break, or tab; it should be formatting the strings according to rules just like it colours them. when written to a .st or .changes file any comments etc should be just long strings with only CRs & tabs as inserted by the author. And if we got the auto-formatting working well they would probably be very rare.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim There can never be a computer language in which you cannot write a bad program.
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
commits＠source.squeak.org -
Jakob Reschke -
Marcel Taeumel -
Nicolas Cellier -
Taeumel, Marcel
-
tim Rowledge