Re: master 97400c4c24: Make printing mostly non-recursive (bug#55481)

Re: master 97400c4c24: Make printing mostly non-recursive (bug#55481)

[Po Lu]

Mattias Engdegård <mattiase@acm.org> writes:

> +struct print_pp_entry {
> +  ptrdiff_t n;			/* number of values, or 0 if a single value */
> +  union {
> +    Lisp_Object value;		/* when n = 0 */
> +    Lisp_Object *values;	/* when n > 0 */
> +  } u;
> +};
> +
> +struct print_pp_stack {
> +  struct print_pp_entry *stack;	 /* base of stack */
> +  ptrdiff_t size;		 /* allocated size in entries */
> +  ptrdiff_t sp;			 /* current number of entries */
> +};

Thanks; however, I think our coding style is to put the opening brace of
structs, enums and unions on column 1, so this should be:

> +struct print_pp_entry
> +{
> +  ptrdiff_t n;			/* number of values, or 0 if a single value */
> +  union
> +  {
> +    Lisp_Object value;		/* when n = 0 */
> +    Lisp_Object *values;	/* when n > 0 */
> +  } u;
> +};
> +
> +struct print_pp_stack
> +{
> +  struct print_pp_entry *stack;	 /* base of stack */
> +  ptrdiff_t size;		 /* allocated size in entries */
> +  ptrdiff_t sp;			 /* current number of entries */
> +};

Instead.

Re: master 97400c4c24: Make printing mostly non-recursive (bug#55481)

[Mattias Engdegård]

18 maj 2022 kl. 11.55 skrev Po Lu <luangruo@yahoo.com>:

>  I think our coding style is to put the opening brace of
> structs, enums and unions on column 1

I wasn't sure and there appeared to be considerable variation in the existing source (almost 300 cases of bracket on the same line, against 500-something with the bracket on a separate line), so I went with the former since it is more economic in vertical space without worsening readability.

Naturally I'll change if that is important, but then there's a lot of code to change, and apparently there is no clear consensus among previous authors.

Re: master 97400c4c24: Make printing mostly non-recursive (bug#55481)

[Po Lu]

Mattias Engdegård <mattiase@acm.org> writes:

> I wasn't sure and there appeared to be considerable variation in the
> existing source (almost 300 cases of bracket on the same line, against
> 500-something with the bracket on a separate line), so I went with the
> former since it is more economic in vertical space without worsening
> readability.

Unfortunately, that contradicts our own coding standards.

> Naturally I'll change if that is important, but then there's a lot of
> code to change, and apparently there is no clear consensus among
> previous authors.

All of that code is formatted incorrectly, but reformatting existing
code breaks various things, such as vc-annotate.  What I think is wrong
is to introduce new instances of the incorrect formatting (such as
here), since our coding standards say:

  For struct and enum types, likewise put the braces in column one,
  unless the whole contents fits on one line:

    struct foo
    {
      int a, b;
    }

  or

    struct foo { int a, b; }