Re: Indentation, tabs, and spaces (was re: [PATCH] support: Implement TEST_COMPARE_STRING)

[Florian Weimer <fweimer at redhat dot com>]

* Zack Weinberg:

> On Wed, Nov 7, 2018 at 6:55 AM Florian Weimer <fweimer@redhat.com> 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,
though.

> 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
non-normalized whitespace.

Thanks,
Florian