I'm mostly in agreement with Eliot here; I don't particularly *like* the look of code done that way but I do appreciate the (relative) consistency that the heuristic provides. It is decently documented and explained, and that means one can use it sensibly.

Also, 'prettyDiffs'. If the diffs are calculated after prettyprinting then nearly all the format related differences are invisible. Maybe that helps? Try changing the preference 'diffs with pretty print' to true.

A couple of related thoughts - 

Could we make Shout do the pretty printing? (Does it already?) It's analysing code anyway, and outputting the code with all that prettiness info, so would it not be a good place to do the formatting for pretty-print too?

Since Shout is now pretty well established, and so far as I can tell any plausible machine we run Squeak on is fast enough to be using it, should we not short-circuit the process whereby text is displayed and then rather quickly replaced by Shout? It was a sensible option years ago when the analysis could take enough time to be irritating, but it seems daft to double up on the rendering these days.

I notice the SHParserST80 class>>#benchmark method and on running (on the Pi 4 as usual) the figures are quite interesting -
	Methods		93326
	Total			13229.046ms
	Average		0.142ms
	Min				0.007ms 1 range(s) (ASN1InputStream>>#asCharacter)
	Median			0.060ms 17 ranges (StrikeFont class>>#primitiveCreateFont:size:flags:weight:)
	80th percentile	0.175ms 41 ranges (WAResponseTest>>#testStreaming)
	95th percentile	0.454ms 118 ranges (Trait class>>#named:uses:category:env:)
	99th percentile	0.999ms 217 ranges (PBPreferenceView>>#offerPreferenceNameMenu:)
	Max			217.314ms 128595 ranges (StrikeFont class>>#dejaVuSansBold13Data)
So the very worst case is still barely 10 frame cycles and the 99th %ile level is under 1mS, on the slowest likely host machine.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Hex dump:  Where witches put used curses...