Woops, pardon me, Marcel!  I have been running with my own version of that
method for so long (since 2010), I forgot this was not how it was for
everybody.  Please consider Compiler-cmm.480 in the Inbox.  I forgot that
Squeak is still mangling comments for everyone else.

Comments are humans talking to humans.  It seems to me that the machine has
no business getting into the middle of this.  It makes pretty print
unusable.  For the code that talks to the machine, its great, but I can't
let it get into messing up my comments that are crafted for human
consumption.

Squeak already has an Indent feature built into Text or TextMorph...
somewhere.  It would be cool if CodeEditor could take advantage of that.
There are also tools to help us hand-craft like [Tab] when a multi-line
selection is selected to do tab indentation.

But, IMO, comment formatting should _not_ be part of pretty print.

Best,
  Chris

On Wed, Jul 13, 2022 at 1:38 AM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> Hi Chris --
>
> > Speaking of which, WHAT in the heck happened to comment
> > formatting in 6.0?  We've held off improving the pretty printer
> > to emulate Rectangular Block for years out of respect for original
> > authors chosen legacy format.  But this new comment formatting
> > blows that out of the water by changing peoples' **custom-formatted**
> > comments to  a horrendously narrow, super-tall format!  Please
> > revert ParseNode>>#printSingleComment:on:indent:.
>
> Hmm... let's unpack this. The only change in that method was:
>
> - tabWidth := TextConstants at: #DefaultTab.
> + tabWidth := TextStyle default tabWidth.
>
> So, that never changing constant of "24" is now dependent on the
> current scale factor or whatever the user configures via
>    TextStyle numSpacesPerTab
>
> Interesting to see that there seems to be a strange side effect to
> what the pretty printer is doing. I cannot see a a conceptual relationship
> at a glance. Maybe the entire algorithm considering the pixel width
> here is kind of broken.
>
> Sure, we can revert this BUT I would revert it to use a straight
>    24
> and not that value from TextConstants. From there, we can figure
> out a way to improve the algorithm
>
> :-)
>
> Best,
> Marcel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220713/8c239b79/attachment.html>