[MPlayer-dev-eng] the great reformatting

[Ingo Brückl]

Clément Boesch wrote on Tue, 22 Feb 2011 12:18:21 +0100:

>> (BTW, I don't get whether aligning of var_def is favored, while var_struct
>> isn't. I, as mentioned, would vote against all aligning :), but if that's
>> convention, shouldn't it be consistent?)

> The var align set to 1 seems to force only 1 space, so in fact, no
> alignment. Do you see a better option?

I'm not sure I get your point here. With align_var_def_span and
align_var_struct_span set I'll get:

typedef struct {
    fntChar       Fnt[ASCII_CHRS + EXTRA_CHRS];
    unsigned char nonASCIIidx[EXTRA_CHRS][UTF8LENGTH];
    txSample      Bitmap;
    char          name[MAX_FONT_NAME];
} bmpFont;

and

    int            size = 0;
    gboolean       utf8;
    unsigned char *p;

Isn't that the favored alignment?

Unset these options and it is:

typedef struct {
    fntChar Fnt[ASCII_CHRS + EXTRA_CHRS];
    unsigned char nonASCIIidx[EXTRA_CHRS][UTF8LENGTH];
    txSample Bitmap;
    char name[MAX_FONT_NAME];
} bmpFont;

and

    int size = 0;
    gboolean utf8;
    unsigned char *p;

> The issue is not the inside parens, fntRead(char *path, char *fname) is
> correct, the spaces between the type and the function name isn't.

Oh! I see. You're looking for sp_func_def_paren.

> Also, this means a lot of extra spaces have to be removed but aren't
> (typedef       foo       bar    ; for instance).

sp_after_type (at least for the "foo bar;" part). I'm not sure there is one
for the typedef part.

>> [...]
>> int fntRead(char *path, char *fname)
>> {
>>     FILE          *f;
>>     unsigned char  tmp[512];
>>     unsigned char *ptmp;
>>     unsigned char  command[32];
>>     unsigned char  param[256];
>>     int            id, n;
>>

> This alignement is wrong, we need to remove it; it's relative to what I
> said previously.

It's the align_var_def_span you changed earlier.

So, should variable declaration be aligned or not?

>>             if (!utf8 && (Fonts[id]->nonASCIIidx[i][0] == (*uchar >> 6 | 0xc0) && Fonts[id]->nonASCIIidx[i][1] == ((*uchar & 0x3f) | 0x80) && Fonts[id]->nonASCIIidx[i][2] == 0))

> Huh? We need the 80 column setting too if it exists...

I'm afraid that's up to the programmer. Manually changed to:

            if (!utf8 &&
                (Fonts[id]->nonASCIIidx[i][0] == (*uchar >> 6 | 0xc0) &&
                 Fonts[id]->nonASCIIidx[i][1] == (*uchar & 0x3f | 0x80) &&
                 Fonts[id]->nonASCIIidx[i][2] == 0))
                c = i + ASCII_CHRS;

What's the general convention concerning 80 columns? For example, I don't
like breaking function arguments into different lines if only the last
argument reaches a little bit beyond this 80-column-border.

Ingo