On Sat, Aug 13, 2011 at 8:41 AM, Nicolas Cellier <
[email protected]> wrote:

> 2011/8/13 Stéphane Ducasse <[email protected]>:
> >
> > On Aug 12, 2011, at 3:58 PM, Lukas Renggli wrote:
> >
> >> On 12 August 2011 15:42, Stéphane Ducasse <[email protected]>
> wrote:
> >>> I mean that I prefer
> >>>
> >>>>> Smalltalk tools
> >>>>>                register: ;lkl;k;lk;l
> >>>>>                in: lkl;k;lkl;kl;
> >>>
> >>> over
> >>>
> >>>>> Smalltalk tools register: ;lkl;k;lk;l
> >>>>>                in: lkl;k;lkl;kl;
> >>>
> >>>
> >>> because I do not see fast that the message is register: in:
> >>
> >> Hmm, I still don't understand your example because the $; has semantic
> >> meaning and because the  example doesn't even compile :-)
> >
> >>>>> Smalltalk tools
> >>>>>                register: 'string'
> >>>>>                in: 'hkjjkhkhjh'
> >
> > :)
> >
> >
> >
> >>
> >>> and I guess that you are formatting the way I like but the rb formatter
> may be wrong because
> >>
> >> You can configure after how how many keyword parts (that is probably
> >> too low right now) it should print on one line. Also you can tell it
> >> how many characters per line you maximally want (used to be 80, I
> >> think i changed the default to 100; but probably should be inifite).
> >>
> >
> > I will play with it.
> > I'm really thinking that having a systematic formatting of code within
> the core would be good.
> >
>
> The thing that upsets me most is auto-formatting of literals.
>
> 1) the formatter SHALL try to preserve the indenting of array literals
>   A 256 elements table organised in a 16x16 fashion can be legible.
>   A rough 256 element suit is not.
> 2) the formatter SHALL preserve the base used to specify a number literal
>   If i write 2r1011 it's clearly not my intention to read 11.
>   It's the same for number composing a literal array/byte array
>
> In other words, the literals shall better be left unchanged.
>

+2 raisedTo: SmallInteger maxVal


>
> The second thing that is annoying is that it can become hard to
> compare code and track evolutions.
> But this one is just a question of having the right tool to perform
> the comparison...
> I always thought that MC, change list and friends should propose an
> option that simply compares scanned tokens and optionnally ignore
> comments.
>
> Nicolas
>
> >
> >> Lukas
> >>
> >>>
> >>> On Aug 12, 2011, at 1:49 PM, Lukas Renggli wrote:
> >>>
> >>>> Hmm, I don't get your example.
> >>>>
> >>>> What I changed is that the formatter does not enforce the useless
> >>>> parenthesis around the receiver of a cascade. Can be disabled though.
> >>>>
> >>>> Also note that there are settings to automatically format code on
> >>>> display and/or accept. I use the "on display" mode often to read ugly
> >>>> code :-)
> >>>>
> >>>> Lukas
> >>>>
> >>>> On 12 August 2011 13:29, Stéphane Ducasse <[email protected]>
> wrote:
> >>>>> Yes
> >>>>>
> >>>>>        Smalltalk tools
> >>>>>                register: ;lkl;k;lk;l
> >>>>>                in: lkl;k;lkl;kl;
> >>>>>
> >>>>>
> >>>>> stef
> >>>>> On Aug 12, 2011, at 1:20 PM, Lukas Renggli wrote:
> >>>>>
> >>>>>>> I always think of this a the Seaside style, but I am not sure if
> that is a correct attribution.
> >>>>>>
> >>>>>> Haha, thank you.
> >>>>>>
> >>>>>> Actually the refactoring browser formatter with the default settings
> >>>>>> is quite close to the Seaside style, I just recently submitted some
> >>>>>> fixes for cascades. The only thing that I don't like about the
> >>>>>> automatic formatter is how the brackets in multiline blocks are
> >>>>>> aligned. Anyway, the formatter would style #inject:into: as you
> >>>>>> suggest.
> >>>>>>
> >>>>>> Lukas
> >>>>>>
> >>>>>> --
> >>>>>> Lukas Renggli
> >>>>>> www.lukas-renggli.ch
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Lukas Renggli
> >>>> www.lukas-renggli.ch
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> Lukas Renggli
> >> www.lukas-renggli.ch
> >>
> >
> >
> >
>
>


-- 
best,
Eliot

Reply via email to