Inlining strikes again!

Turns out that pretty printing rewrites #ifFalse:ifTrue: to
#ifTrue:ifFalse:

Looks like it actually happens as Macro Transformation, see
MessageNode>>transformIfFalseIfTrue:

Bummer! This sort of thing is rather serious weakness, IMHO, of the
current parse tree based pretty printing and colorizing. The parse trees
just aren't rich enough. Having colorizing, especially, being tied to the
parse tree just hurts since colorizing *can* preserve other code layout
(and I know there's a package floating around for that).

I guess the other bummer about parse tree based pretty printing and
colorizing is that it makes it impossible to do these things on the
fly, since you need a valid method string for them to work.

Makes me think of using decompilition in systems without source...you lose
variable names, etc. It's clever but I *like* variable names and comments
:)

There seems to be 2 and a half to 4 and a quarter (maybe more) ways of
diddlying textual code representation in Squeak (oh! not to mention *file
out* formats!). (I'm also thinking of things like tiles and bytecodes.) I
know that folks have, now and again, put forth ideas for generalizing and
streamlining this framework. I'd like you all to pipe up again :)

I'd love to be able to switch between langauges (not just syntaxes) like
Prolog/V, or squeak server pages (themselves, perhaps further
specializable to things like HTML, etc.; but no icky pragmas!), or
Piccola! And I'd like these sorts of options to be able to specialize
colorizing, pretty printing and the like in a rational way.

I have some details at least highlighted in the november squeak tweaks
column (more HTML editor). But I just hit this and I thought I'd whine a
bit about it.

(At least I didn't go on about wanting...well, I won't go on about it!)

Cheers,
Bijan Parsia.