<div dir="ltr"><div dir="ltr">Hi Marcel,</div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-m_1161276196122988614__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);text-align:left" dir="ltr"><div>Please make sure to have Text >> #format: be on par with your changes.</div></div></blockquote><div><br></div><div>Hmm, I noticed that, but am hesitant to continue encouraging Text to take on that responsibility.  Text is concerned with presentation -- attributes, colors, fonts -- and not really the domain side, which is what #format: is dealing with.  I see the existing implementation is optimized by directly accessing its 'runs', which I would not do.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-m_1161276196122988614__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);text-align:left" dir="ltr"><div><span style="font-size:10pt">Note that you changes put more pressure on the GC:</span><br></div><div><br></div><div><div><span style="font-size:13.3333px">['Hello {1}!' format: { 'Squeak' }] bench</span></div><div><span style="font-size:13.3333px"><br></span></div><div><span style="font-size:13.3333px">BEFORE: '2,320,000 per second. 432 nanoseconds per run. 1.63967 % GC time.' </span></div><div><span style="font-size:13.3333px">AFTER: '1,340,000 per second. 746 nanoseconds per run. 16.92 % GC time.' </span></div></div></div></blockquote><div><br></div><div>See Collections-cmm.1018, which restores (mostly) the legacy performance when using numeric-only tokens.  The garbage you saw is necessary when using alphanumeric tokens.  This optimization complexifies the code to the limit of what I believe is reasonable to achieve extra performance.  I think people generally expect String manipulation to involve the need to produce some garbage.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-m_1161276196122988614__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);text-align:left" dir="ltr"><div><span style="font-size:10pt">P.S.: </span><span style="font-size:10pt">If you had not opted for re-layouting the entire method, I would be able to actually see what you changed there... ;-) ... pretty-print for obfuscation, I suppose? :-D</span><br></div></div></blockquote><div><br></div><div>For obfuscation?  Give me a break, absolutely not.  Huh?  No, I've always been a supporter of preserving the formats of original works, especially when only superficial changes are being made, but this is a long method and the change is too complex for me to be expected not to utilize what I need to be productive, which includes the use of my pretty printer, yes.</div><div><br></div><div>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:.</div><div><br></div><div>Best,</div><div>  Chris</div></div></div>