Hey Christoph, hey all, sorry, but I care about this one.  :/

Everyone agrees that pretty-printers are useful, it's about the
responsibility and activation.  You overlooked my question about the
philosophical inversion of the responsibility, from the developer to
the machine.  Tools should *empower* the developer with convenient
activation of PLUS operations *if desired*, NOT take over and
obliterate their intentional formatting and force them into an even
more-distracting corrective operation.

It isn't clear what problem you're trying to solve, and you also
ignored the question of why #browseWithPrettyPrint doesn't already
solve it.

It can't be Tom's vision, because you would need a postscript to
reformat all methods in the system.  So, it seems like you're still going
to have to rely on #browseWithPrettyPrint in any case.  Anything more
is an overstep against the developer.

I'm doubtful consensus on what the stored format should be could ever
be achieved, and whether it would even be healthy if it "could".  Even you
yourself may change your mind one day about a particular formatting
rule, so what good will it been to have rewritten all the code
libraries, instead of simply adjusting your (and, each, their own)
#browseWithPrettyPrint?

> these are very good points for further and tighter integration of a pretty printer into the system (I'm mainly referring to customized and project-specific settings), and I'm sure that Tom and his team will consider at least some of them for PoppyPrint. :-) Nevertheless, I don't think that we should hesitate to integrate new features like this one into the Trunk as experimental features.

The Inbox is for experimental features.  The Trunk is for finished
features that integrate in a cohesive way.  Piling on features that
don't integrate cohesively are detrimental to the IDE.

> Unless turned on by default, I don't see how this could harm anyone,

It harms the IDE by violating a basic premise of not
controlling the developer.  The simplest, best IDE's are
one's made up of "Unconditional Plus Actions".  This preference
introduces behavior conditioned on yet another new global.  Imagine
trying to explain this to a student who just lost their artfully-formatted
code.  Having to explain "pretty-print" with, vs. without, this feature.
Again, #browseWithPrettyPrint avoids these issues.

> but it allows certain users to configure their image to better match their individual preference, so we can give them more freedom. I think we should be more open to and supportive of new ideas, even if they do not perfectly fit
> together.

Marcel is plenty open and supportive of new ideas.  You should
stick to the core _specific_ arguments for this.  These abstract
platitudes could be argued for any idea about anything..

> At the moment, the preference offers a working prototype that interested users can enable - when working on projects that do not enforce a different coding style - and benefit from additional convenience while writing their code.

You mean sparing one hot-key press per method save? (<-- except, NOT,
see? -->)  That's not much convenience, because the imperfect formatter
won't always do what you want.  Then, you'll have to click back in and
re-edit the method, press "Save" again, ... except, OOPS!  Wait, it
overrode you the developer *again*, so simply temporarily turn off this
preference, re-edit a third time, THEN save again, THEN turn the pref
back on...??

If the above "never happens", then you could simply use
#browseWithPrettyPrint.  If it does, you would use up the entire day's
added "convenience" the very first time it happened (believe me, it
would).

> I'm liking this feature very much while developing my latest project. I'm also making good experiences with the analogous concept in the JavaScript world (VS Code "formatOnSave" + eslint) these days.

It's a bad idea there, too.  They should improve to be more empowering
like Squeak.  Please have faith that Squeak's designers have thought
through some of these things since the 1970's, and sometimes have
better ideas than the new kids on the block..  :)

> > Squeak Trunk should not do that [enforce such formatting]
>
> I'm not requesting that here. At least not yet. This will enough stuff for a future discussion. :-)

Reading and writing code is a personal thing.  As long as it's
basically readable, code in the library should reflect the
individuals' style who contributed it.  IMO, stripping away that
personalization from everyone would not only be harmful to the
class-library, it could stifle creative energy and ways of thinking,
and possibly even foster resentment.  Some see this level of control
as overbearing and petty, especially in the presence of
#browseWithPrettyPrint, and so it could cause "formatting" to end up
becoming the very thing you wanted to avoid, a major distraction.

> > it should [...] rather be done at commit time (or code-review time)
>
> -1. :-) The idea of automatic pretty-printing is that you do not have to spend any time or thoughts on thinking about the proper formatting of a method. Thus the earlier automatic pretty-printing is applied, the less the programmer gets distracted by thinking about manual formatting.

We already don't have to.  Pretty-printing is already a useful
feature, as long as I can apply it easily, when and where I want to,
and not have to "fight" against it where I don't want it.  Again, with
#browseWithPrettyPrint, you shouldn't either...

> I would even love to try out pretty-printing as you type, but this would be technically more challenging.

OMG, that is exactly when you would get *distracted* by it!  The text
editor not behaving as you expect because it's busy "formatting" while
you're simply trying to "input".  Also, I like to left-justify
debugging code, I actually want it to NOT be formatted in..
Pretty-print is just right the way it is, #acceptWithPrettyPrint is a
bad idea to add to the IDE, IMO.

Best,
  Chris