Re: AW: [HACKERS] LONG varsize - how to go on (pgindent)

Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> writes:
> I think the idea at that time was also, that with a tab only setup
> people can look at the code with 2 space, 3 space and 4 space indents,
> whatever suits them best.

Not really. If the code still looked OK at different tab widths, people
wouldn't be complaining. A fairly typical example is

if (root->query_pathkeys == NIL ||
pathkeys_contained_in(root->query_pathkeys,
final_rel->cheapestpath->pathkeys))
{
root->query_pathkeys = final_rel->cheapestpath->pathkeys;

which is really

<tb>if (root->query_pathkeys == NIL ||
<tb><tb>pathkeys_contained_in(root->query_pathkeys,
<tb><tb><tb><tb><tb><tb><tb> final_rel->cheapestpath->pathkeys))
<tb>{
<tb><tb>root->query_pathkeys = final_rel->cheapestpath->pathkeys;

so at 8-space tab expansion it looks like

if (root->query_pathkeys == NIL ||
pathkeys_contained_in(root->query_pathkeys,
final_rel->cheapestpath->pathkeys))
{
root->query_pathkeys = final_rel->cheapestpath->pathkeys;

and in fact at any tab spacing other than 4, it will look bizarre.

Things get even worse for declarations and comments in the right margin:

typedef struct Unique
{
Plan plan; /* noname node flattened out */
Oid nonameid;
int keycount;
char *uniqueAttr; /* NULL if all attrs, or unique attribute
* name */
AttrNumber uniqueAttrNum; /* attribute number of attribute to select
* distinct on */
UniqueState *uniquestate;
} Unique;

is really

typedef struct Unique
{
<tb>Plan<tb><tb>plan;<tb><tb><tb>/* noname node flattened out */
<tb>Oid<tb><tb><tb>nonameid;
<tb>int<tb><tb><tb>keycount;
<tb>char<tb> *uniqueAttr;<tb><tb>/* NULL if all attrs, or unique attribute
<tb><tb><tb><tb><tb><tb><tb><tb> * name */
<tb>AttrNumber<tb>uniqueAttrNum;<tb>/* attribute number of attribute to select
<tb><tb><tb><tb><tb><tb><tb><tb> * distinct on */
<tb>UniqueState *uniquestate;
} Unique;

so at 8-space tabs it looks like

typedef struct Unique
{
Plan plan; /* noname node flattened out */
Oid nonameid;
int keycount;
char *uniqueAttr; /* NULL if all attrs, or unique attribute
* name */
AttrNumber uniqueAttrNum; /* attribute number of attribute to select
* distinct on */
UniqueState *uniquestate;
} Unique;

and again, it's not going to look right at any tab width except 4.

> Most Programmers editors (and vi) can handle the 4 space tabs perfectly.

Anyone who can't persuade his editor to show tabs as 4 spaces isn't
going to be contributing to Postgres, because he's not going to find
the code readable. So it's not surprising that the population of this
list considers it a non-problem; natural selection has eliminated the
people who might complain. But I'd like to get rid of that barrier
to new contributors. How many potential contributors have we lost
because they took one look at the code and decided it was too ugly
even to think of working with?

If changing the tabs is too radical, it'd at least be a good idea to add
a section to the Developers' FAQ explaining how to set up all the common
editors for Postgres. I can contribute a recipe for Emacs, but I have
no idea how to do it for vi or anything else...

regards, tom lane