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

  Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
---
 .clang-format | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
  

On Tue, Jun 20, 2023, at 1:17 PM, Yonggang Luo via Libc-alpha wrote:
> -TabWidth:        8
> -UseTab:          Always
> +TabWidth:        2
> +UseTab:          Never ForEachMacros:

This is not right.  GNU style is two spaces per *indent level*, but you
*are* supposed to use hard tabs to compress all runs of 8*n spaces at
the beginning of a line, regardless of the semantics of the spaces (i.e.
unlike some other styles, it doesn't matter whether the spaces represent
nesting or alignment).  I *thought* this was documented somewhere in
https://www.gnu.org/prep/standards/html_node/ but I can't find it (but I
have personally been yelled at on this very mailing list for screwing it
up, so I don't want you to have the same experience).

Whether clang-format can do this correctly, I do not know.

zw
  

On Wed, Jun 21, 2023 at 1:45 AM Zack Weinberg <zack@owlfolio.org> wrote:
>
> On Tue, Jun 20, 2023, at 1:17 PM, Yonggang Luo via Libc-alpha wrote:
> > -TabWidth:        8
> > -UseTab:          Always
> > +TabWidth:        2
> > +UseTab:          Never ForEachMacros:
>
> This is not right.  GNU style is two spaces per *indent level*, but you
> *are* supposed to use hard tabs to compress all runs of 8*n spaces at

I am trying to stop using Tab in the code base, so I don't understand
what's your
concern, before the patch, the clang-format tried to use an 8 spaces width
tab to  indent  code.
After this patch, the clang-patch always uses 2 spaces to indent code.

> the beginning of a line, regardless of the semantics of the spaces (i.e.
> unlike some other styles, it doesn't matter whether the spaces represent
> nesting or alignment).  I *thought* this was documented somewhere in
> https://www.gnu.org/prep/standards/html_node/ but I can't find it (but I
> have personally been yelled at on this very mailing list for screwing it
> up, so I don't want you to have the same experience).
>
> Whether clang-format can do this correctly, I do not know.
>
> zw



--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo
  

On Wed, 2023-06-21 at 14:31 +0800, 罗勇刚(Yonggang Luo) via Libc-alpha wrote:
> On Wed, Jun 21, 2023 at 1:45 AM Zack Weinberg <zack@owlfolio.org> wrote:
> > 
> > On Tue, Jun 20, 2023, at 1:17 PM, Yonggang Luo via Libc-alpha wrote:
> > > -TabWidth:        8
> > > -UseTab:          Always
> > > +TabWidth:        2
> > > +UseTab:          Never ForEachMacros:
> > 
> > This is not right.  GNU style is two spaces per *indent level*, but you
> > *are* supposed to use hard tabs to compress all runs of 8*n spaces at
> 
> I am trying to stop using Tab in the code base, so I don't understand
> what's your
> concern, before the patch, the clang-format tried to use an 8 spaces width
> tab to  indent  code.
> After this patch, the clang-patch always uses 2 spaces to indent code.

Because the existing code uses one tab for 8 spaces.  Glibc has its own
coding standard, not "what you prefer".
  

On Wed, Jun 21, 2023 at 2:47 PM Xi Ruoyao <xry111@xry111.site> wrote:
>
> On Wed, 2023-06-21 at 14:31 +0800, 罗勇刚(Yonggang Luo) via Libc-alpha wrote:
> > On Wed, Jun 21, 2023 at 1:45 AM Zack Weinberg <zack@owlfolio.org> wrote:
> > >
> > > On Tue, Jun 20, 2023, at 1:17 PM, Yonggang Luo via Libc-alpha wrote:
> > > > -TabWidth:        8
> > > > -UseTab:          Always
> > > > +TabWidth:        2
> > > > +UseTab:          Never ForEachMacros:
> > >
> > > This is not right.  GNU style is two spaces per *indent level*, but
you
> > > *are* supposed to use hard tabs to compress all runs of 8*n spaces at
> >
> > I am trying to stop using Tab in the code base, so I don't understand
> > what's your
> > concern, before the patch, the clang-format tried to use an 8 spaces
width
> > tab to  indent  code.
> > After this patch, the clang-patch always uses 2 spaces to indent code.
>
> Because the existing code uses one tab for 8 spaces.  Glibc has its own
> coding standard, not "what you prefer".

I am also talking about the existing code, so the conclusion is the
existing code
is not consistent, some use one tab for 8 spaces, some use spaces directly

>
> --
> Xi Ruoyao <xry111@xry111.site>
> School of Aerospace Science and Technology, Xidian University



--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo
  

On Wed, 2023-06-21 at 14:55 +0800, 罗勇刚(Yonggang Luo) wrote:
> > Because the existing code uses one tab for 8 spaces.  Glibc has its own
> > coding standard, not "what you prefer".
> 
> I am also talking about the existing code, so the conclusion is the existing code 
> is not consistent, some use one tab for 8 spaces, some use spaces directly

Anyway "TabWidth: 2" is wrong.  If you want to avoid tab at all, the
TabWidth setting is irrelevant and should be removed.

We already have "UseTab: Always" and "IndentWidth: 2", these matches the
description of Zack.  As the patch adding .clang-format had been
reviewed (the commit adding it even contains an R-b tag from Carlos), it
implies the current consensus for new code is to *always* tabs for 8
spaces.
  

On Tue, 2023-06-20 at 13:45 -0400, Zack Weinberg via Libc-alpha wrote:
> I *thought* this was documented somewhere in
> https://www.gnu.org/prep/standards/html_node/ but I can't find it (but I
> have personally been yelled at on this very mailing list for screwing it
> up, so I don't want you to have the same experience).

It's implied by:

"""
The rest of this section gives our recommendations for other aspects of
C formatting style, which is also the default style of the indent
program in version 1.2 and newer. It corresponds to the options

-nbad -bap -nbc -bbo -bl -bli2 -bls -ncdb -nce -cp1 -cs -di2
-ndj -nfc1 -nfca -hnl -i2 -ip5 -lp -pcs -psl -nsc -nsob
"""

There is no -nut.
  

On Wed, Jun 21, 2023 at 3:13 PM Xi Ruoyao <xry111@xry111.site> wrote:
>
> On Wed, 2023-06-21 at 14:55 +0800, 罗勇刚(Yonggang Luo) wrote:
> > > Because the existing code uses one tab for 8 spaces.  Glibc has its
own
> > > coding standard, not "what you prefer".
> >
> > I am also talking about the existing code, so the conclusion is the
existing code
> > is not consistent, some use one tab for 8 spaces, some use spaces
directly
>
> Anyway "TabWidth: 2" is wrong.  If you want to avoid tab at all, the
> TabWidth setting is irrelevant and should be removed.
>
> We already have "UseTab: Always" and "IndentWidth: 2", these matches the
> description of Zack.  As the patch adding .clang-format had been
> reviewed (the commit adding it even contains an R-b tag from Carlos), it
> implies the current consensus for new code is to *always* tabs for 8
> spaces.
>
> --
> Xi Ruoyao <xry111@xry111.site>
> School of Aerospace Science and Technology, Xidian University

The output of clang-format --style=GNU -dump-config is:
```
StatementMacros:
  - Q_UNUSED
  - QT_REQUIRE_VERSION
TabWidth:        8
UseCRLF:         false
UseTab:          Never
WhitespaceSensitiveMacros:
  - STRINGIZE
  - PP_STRINGIZE
  - BOOST_PP_STRINGIZE
  - NS_SWIFT_NAME
  - CF_SWIFT_NAME
```
So yeah, UseTab: Never is enough.


--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo
  

On Wed, Jun 21, 2023, at 2:31 AM, 罗勇刚(Yonggang Luo) wrote:
> On Wed, Jun 21, 2023 at 1:45 AM Zack Weinberg <zack@owlfolio.org> wrote:
> > On Tue, Jun 20, 2023, at 1:17 PM, Yonggang Luo via Libc-alpha wrote:
> > > -TabWidth:        8
> > > -UseTab:          Always
> > > +TabWidth:        2
> > > +UseTab:          Never ForEachMacros:
> >
> > This is not right.  GNU style is two spaces per *indent level*, but you
> > *are* supposed to use hard tabs to compress all runs of 8*n spaces [...]
> 
> I am trying to stop using Tab in the code base

I sympathize with this goal, but you cannot make this change by yourself,
without any discussion or agreement -- and because the policy comes from
the GNU coding standards, you would need to have that discussion on the
GNU standards mailing list (https://lists.gnu.org/mailman/listinfo/bug-standards).
In my opinion, this particular change is very unlikely to be accepted
there, and I do not think the argument would be a good use of your time.
If you choose to try anyway, please *do not* cc the glibc development
list, me, or anyone else involved in this thread.

Please also understand that because glibc is very complicated and patches
are already difficult enough to review, we really need you to keep each
patch series narrowly focused on a single logical change.  Changes to
`.clang-format` should be submitted *independently* of patch series that
do anything else.

zw
  

On 6/20/23 13:45, Zack Weinberg via Libc-alpha wrote:
> On Tue, Jun 20, 2023, at 1:17 PM, Yonggang Luo via Libc-alpha wrote:
>> -TabWidth:        8
>> -UseTab:          Always
>> +TabWidth:        2
>> +UseTab:          Never ForEachMacros:
> 
> This is not right.  GNU style is two spaces per *indent level*, but you
> *are* supposed to use hard tabs to compress all runs of 8*n spaces at
> the beginning of a line, regardless of the semantics of the spaces (i.e.
> unlike some other styles, it doesn't matter whether the spaces represent
> nesting or alignment).  I *thought* this was documented somewhere in
> https://www.gnu.org/prep/standards/html_node/ but I can't find it (but I
> have personally been yelled at on this very mailing list for screwing it
> up, so I don't want you to have the same experience).

It would be complete unacceptable to yell at anyone in person or virtually in this
community for getting this wrong. We should be kind and sympathetic to developers
working on our project and provide them with the tools they need to avoid these
problems.

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.
  

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).
  

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, and Emacs is not the sole editor,
I am not using Emcas,
For other editors, 8 tab is rare, so when I am reading the glib code, the
indent mixed space/tab looks weird


>
> --
> Joseph S. Myers
> joseph@codesourcery.com



--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo
  

On Wed, Jun 21, 2023 at 10:42 AM 罗勇刚(Yonggang Luo) via Libc-alpha
<libc-alpha@sourceware.org> 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, and Emacs is not the sole editor,
> I am not using Emcas,
> For other editors, 8 tab is rare, so when I am reading the glib code, the
> indent mixed space/tab looks weird

Note vi defaults to 8 spaces to a tab too.
I suspect the non-8 spaces are non-UNIX first editors. I know
notepad++ defaults to 4 spaces but I changed the settings there to 8
because I actually like 8 spaces to the tab idea; 4 seems too little.

Thanks,
Andrew Pinski

>
>
> >
> > --
> > Joseph S. Myers
> > joseph@codesourcery.com
>
>
>
> --
>          此致
> 礼
> 罗勇刚
> Yours
>     sincerely,
> Yonggang Luo
  

On Thu, Jun 22, 2023 at 1:49 AM Andrew Pinski <pinskia@gmail.com> wrote:
>
> On Wed, Jun 21, 2023 at 10:42 AM 罗勇刚(Yonggang Luo) via Libc-alpha
> <libc-alpha@sourceware.org> 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, and Emacs is not the sole
editor,
> > I am not using Emcas,
> > For other editors, 8 tab is rare, so when I am reading the glib code,
the
> > indent mixed space/tab looks weird
>
> Note vi defaults to 8 spaces to a tab too.
> I suspect the non-8 spaces are non-UNIX first editors. I know
> notepad++ defaults to 4 spaces but I changed the settings there to 8
> because I actually like 8 spaces to the tab idea; 4 seems too little.
That‘s why better always using space, so that different editor would show
it consistence
I am using vscode.


>
> Thanks,
> Andrew Pinski
>
> >
> >
> > >
> > > --
> > > Joseph S. Myers
> > > joseph@codesourcery.com
> >
> >
> >
> > --
> >          此致
> > 礼
> > 罗勇刚
> > Yours
> >     sincerely,
> > Yonggang Luo



--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo
  

罗勇刚(Yonggang Luo) via Libc-alpha <libc-alpha@sourceware.org> writes:

>> Note vi defaults to 8 spaces to a tab too.
>> I suspect the non-8 spaces are non-UNIX first editors. I know
>> notepad++ defaults to 4 spaces but I changed the settings there to 8
>> because I actually like 8 spaces to the tab idea; 4 seems too little.
> That‘s why better always using space, so that different editor would show
> it consistence
> I am using vscode.

I agree that in a code style based on spaces, 'compressing' eight spaces
to tabs makes little sense.

The current problem of 'editors configure tabs to a non-standard value
out of the box', however, might be solved by something like an
EditorConfig file, assuming it's not desirable to change the code style
to not compress tabs.

I'm not aware of anything other than EditorConfig that's even remotely
standard (or even cross-editor).
  

On Thu, Jun 22, 2023 at 2:36 AM Arsen Arsenović <arsen@gentoo.org> wrote:
>
> 罗勇刚(Yonggang Luo) via Libc-alpha <libc-alpha@sourceware.org> writes:
>
> >> Note vi defaults to 8 spaces to a tab too.
> >> I suspect the non-8 spaces are non-UNIX first editors. I know
> >> notepad++ defaults to 4 spaces but I changed the settings there to 8
> >> because I actually like 8 spaces to the tab idea; 4 seems too little.
> > That‘s why better always using space, so that different editor would
show
> > it consistence
> > I am using vscode.
>
> I agree that in a code style based on spaces, 'compressing' eight spaces
> to tabs makes little sense.
>
> The current problem of 'editors configure tabs to a non-standard value
> out of the box', however, might be solved by something like an
> EditorConfig file, assuming it's not desirable to change the code style
> to not compress tabs.
>
> I'm not aware of anything other than EditorConfig that's even remotely
> standard (or even cross-editor).
> --
> Arsen Arsenović

Yeap, EditorConfig file is supported for multiple editors, but this
clang-format file
is hard to be supported by the editor:)
Because it's formatted result are mixed tab and space

--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo
  

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
  

On 2023-06-21 10:35, Joseph Myers wrote:
> I don't think the convention of tabs for every eight columns is
> *documented*  GNU style,

Actually, it's documented to be 8:

"Calculate column numbers assuming that space and all ASCII printing 
characters have equal width, and assuming tab stops every 8 columns."

https://www.gnu.org/prep/standards/html_node/Errors.html
  

On Wed, 21 Jun 2023, Paul Eggert wrote:

> On 2023-06-21 10:35, Joseph Myers wrote:
> > I don't think the convention of tabs for every eight columns is
> > *documented*  GNU style,
> 
> Actually, it's documented to be 8:
> 
> "Calculate column numbers assuming that space and all ASCII printing
> characters have equal width, and assuming tab stops every 8 columns."
> 
> https://www.gnu.org/prep/standards/html_node/Errors.html

I think that's about a documented convention for *reading* files - not a 
convention that when *writing* C source files you use tabs rather than 
spaces for a multiple of 8 leading blank columns.
  

On 2023-06-22 14:43, Joseph Myers wrote:
>> On 2023-06-21 10:35, Joseph Myers wrote:
>>> I don't think the convention of tabs for every eight columns is
>>> *documented*   GNU style,
>> Actually, it's documented to be 8:
>>
>> "Calculate column numbers assuming that space and all ASCII printing
>> characters have equal width, and assuming tab stops every 8 columns."
>>
>> https://www.gnu.org/prep/standards/html_node/Errors.html
> I think that's about a documented convention for*reading*  files - not a
> convention that when*writing*  C source files you use tabs rather than
> spaces for a multiple of 8 leading blank columns.

You're right that it doesn't say you must use tabs in source code. But 
if you use tabs, tab stops should be every 8 columns, not every 4 (or 
some other number). Otherwise the guideline makes no sense.

I thought your point was about the "eight columns"; if it was something 
else then please never mind.