Adrian, Another approach would be to have a Seaside app that accepts uploads of .mcz files, loads, formats, and re-saves them into an in-box. I still recommend getting the RB's house in order with respect to comments, but it would work as well as RB users have come to expect. It would also make it part of the release process for a package vs. putting it in the image and affecting "the little guy."
Bill -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Adrian Lienhard Sent: Monday, March 01, 2010 6:53 AM To: [email protected] Subject: Re: [Pharo-project] about code formatting in pharo Cool. If we can tweak the formatter to fit our needs, I think this is an interesting idea because we would then have really consistent formatting. How does one use this formatter? Something else to consider is that we would need to run the formatter in PharoCore, but it does not contain RB. We could write a small web service that takes some method source as input and returns the formatted code ;) Adrian On Feb 28, 2010, at 22:31 , Lukas Renggli wrote: > The configurable formatter can be told from how many keyword messages > on it should put them on multiple lines. Also you can give exceptions > of messages that you always/never want to put on multiple lines. > > Lukas > > On 28 February 2010 22:29, Adrian Lienhard <[email protected]> wrote: >> >> On Feb 28, 2010, at 22:12 , Stéphane Ducasse wrote: >>>> --------------- >>>> 1 >>>> to: (mine size min: his size) >>>> do: [ :index | >>>> (mine at: index) = (his at: index) ifTrue: [ >>>> self >>>> instVarAt: index >>>> put: (anotherObject instVarAt: index) ] ]. >>>> --------------- >>>> >>>> Putting "[ :ind |" on a new line and using multiple tab indentation looks >>>> horrible to me. >>> >>> :) >>> >>> why not like that? >>>> 1 >>>> to: (mine size min: his size) >>>> do: [ :index | >>>> (mine at: index) = (his at: index) >>>> ifTrue: [ self >>>> instVarAt: index >>>> put: (anotherObject instVarAt: index) >>>> ] ]. >> >> The difference is not big, but I prefer the first version because you get >> one indentation less (and you don't break the rule that an indentation >> always has only one tab, which is not the case above). >> >> Also it makes formatting of conditionals consistent with the >> formatting of other messages, e.g., >> >> receiver foo: x >> >> instead of >> >> receiver >> foo: x >> >> >> The rule for ifTrue:ifFalse: follows the same rule, i.e., that keyword >> messages with more than one argument are put on separate lines: >> >> receiver >> foo: x >> bar: y >> >> >> Adrian >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
