Re: [PATCH v3] Align natural-format register values to the same column

[Simon Marchi <simark@simark.ca>]

On 2018-02-03 06:43 AM, Ruslan Kabatsayev wrote:
> I'm extremely sorry for making you repeat your comments. I keep
> missing some formatting bits. Are there any known-working options for
> any linter/indenter so that I could automatically check/prettify my
> GDB patches before posting? I've tried astyle, but it somehow messes
> up spaces/tabs and doesn't seem to support half-indenting enum braces
> (or I didn't use the correct options). GNU indent appears to confuse
> C++ references with bitwise OR, putting spaces on both sides, and also
> doesn't want to half-indent enums.

I don't know of any tool/config that does it right out of the box, but if
you manage to find a solution that works nicely, please share it.  The problem
is often that if you run files through an automatic formatter, you'll have a huge
diff of little changes (fix existing style issues, change how things are wrapped,
etc).  If there was a way to tell the formatter to only touch the lines that were
touched in your patch, it would be ideal.

What do you mean by half-indent enum, do you mean that the curly braces are
indented with respect to the enum keywork, like this?

  enum tab_stops
    {
      value_column_1 = 15,
      /* Give enough room for "0x", 16 hex digits and two spaces in
         preceding column. */
      value_column_2 = value_column_1 + 2 + 16 + 2,
    };

I've seen inconsistent style in GDB between the above, and this:

  enum tab_stops
  {
    value_column_1 = 15,
    /* Give enough room for "0x", 16 hex digits and two spaces in
       preceding column. */
    value_column_2 = value_column_1 + 2 + 16 + 2,
  };

I think the second version makes more sense, because it mimics how it's
done for functions.  But I don't know if it should be different if the
enum is declared inside the scope of a function.  If your formatter
writes it like the second version, I would be totally fine with it.

> I've sent a new version of the patch.

Thanks, I'll look at it later.

Simon