This is the mail archive of the
mailing list for the glibc project.
Re: Indentation, tabs, and spaces (was re: [PATCH] support: Implement TEST_COMPARE_STRING)
- From: Florian Weimer <fweimer at redhat dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 07 Nov 2018 13:47:45 +0100
- Subject: Re: Indentation, tabs, and spaces (was re: [PATCH] support: Implement TEST_COMPARE_STRING)
- References: <CAKCAbMhOr2=peqhfG9rarW15nJT7zA=2AaXPOYGScCBD1aG9qw@mail.gmail.com>
* Zack Weinberg:
> On Wed, Nov 7, 2018 at 6:55 AM Florian Weimer <firstname.lastname@example.org> wrote:
>>* Szabolcs Nagy:
>>> On 07/11/18 11:36, Gabriel F. T. Gomes wrote:
>>>> On Wed, 07 Nov 2018, Florian Weimer wrote:
>>>>> I wasn't aware that we have a policy to use tabs. Most of my changes
>>>>> involving new files do not use tabs. 8-/
>>>> Oh, maybe we don't. Now I feel embarrassed that I complained about it so
>>>> many times.
>>> why is there an awkward mix of space and tab
>>> indentation everywhere in the code then?
>> It's the Emacs default. I don't know about vim.
>> Have we ever discussed changing it?
> The Emacs default behavior (tab stops are fixed at 8 spaces apart,
> indentation width is variable, indent with a mix of tabs and spaces)
> plus the GNU code-formatting standard's 2-space indentation width
> produces text that combines the worst properties of tab-only and
> spaces-only indentation. I'm also constantly getting it wrong,
> especially since every other project I contribute to mandates
> spaces-only indentation so that's what my global settings are.
And non-normalized whitespace leads to spurious source code changes,
which clutters patch submissions.
> I don't recall ever seeing it come up before, but I would support
> either a change to spaces-only, or a change to "tabs for indentation,
> spaces for alignment" (see https://www.emacswiki.org/emacs/SmartTabs
> for more details and an emacs minor mode; I don't know if equivalent
> automation exists for vim).
I have a feeling that smart tabs do not work naturally for compound
statements and other lambda-like constructs. At the very least, it's a
lot of work for the editor to get this right. At this point, it just
can reindent on display, I suppose.
> Spaces-only would be easier to migrate to incrementally.
Yes, and we could enforce it for new lines in most files (except
makefiles and binary files) with a commit hook.
Before we do that, we need to fix the other commit hook problems,
> Smart tabs are abstractly better in some ways but I think we'd have to
> machine-reformat the entire repository to get rid of all the existing
> 8-space tabs.
I think they will be problematic if not enforced by the compiler because
the rules are so complex that editors will differ, resulting again in