[PATCH v2 1/4] clang-format: should format with 2 space and do not usage tab

[Zack Weinberg]

On Wed, Jun 21, 2023, at 1:41 PM, 罗勇刚(Yonggang Luo) wrote:
> On Thu, Jun 22, 2023 at 1:35 AM Joseph Myers <joseph@codesourcery.com> wrote:
> >
> > On Wed, 21 Jun 2023, Carlos O'Donell via Libc-alpha wrote:
> >
> > > It is *my* failing as a steward for the project if we don't make this
> > > easy, and I like clang-format because it makes this easy. I don't
> > > actually care what we pick but we should as project pick something and
> > > make it easy to support developers.
> >
> > Personally I like not using tabs, but (a) the current glibc convention
> > definitely uses tabs and (b) changes like that definitely don't belong in
> > an unrelated patch series.
> >
> > I don't think the convention of tabs for every eight columns is
> > *documented* GNU style, it's more like "GNU style by default because it's
> > what Emacs does by default" (you can stop Emacs doing it with an
> > appropriate .dir-locals.el, but then you need to re-enable tabs in
> > .dir-locals.el for makefile-mode and any other modes that should continue
> > to use tabs).
> 
> clang-format --style=GNU -dump-config
> 
> show the default GNU style won't use tab

That's a bug in clang-format (which is not a GNU project).  For C, the correct
thing to take as the official style is the behavior of `indent -gnu`, and as
already pointed out upthread, that uses tabs as described.

...
> For other editors, 8 tab is rare

8 spaces per tab is not just the norm going back at *least* as far as the VT52,
it's the *only option* in a lot of contexts (e.g. I don't believe there is any
way to configure this at all in most terminal emulators).  Any editor that
defaults to anything else is, therefore, buggy.

zw