Re: [PATCH RFC3 09/13] send-email: Remove horrible mix of tabs and spaces

> On Tue, Apr 14, 2009 at 00:31, Andreas Ericsson <ae@op5.se> wrote:
>> Michael Witten wrote:
>>> On Mon, Apr 13, 2009 at 15:55, Junio C Hamano <gitster@pobox.com> wrote:
>>>> Michael Witten <mfwitten@gmail.com> writes:
>>>>
>>>>> Currently, no lines match the following:
>>>>>
>>>>>    [\t]+[ ]+
>>>>>    [ ]+[\t]+
>>>> I understand the latter but what's wrong with the former?  The width of a
>>>> HT is by definition 8 columns throughout the git codebase.
>>> Ah, well, the width of a HT has been a free variable in my
>>> calculations; I was operating under the assumption that whitespace
>>> used for indentation can float freely according to the user's
>>> settings. A few of the lines were aligning function arguments via tabs
>>> and a few extra spaces, which is not reliable in my model.
>>>
>>> Frankly, I don't like tabs and spaces sharing the same contiguous
>>> block. I don't like it all. ;-B
>> Using tabs to align stuff to indentation level and spaces to align
>> line continuation is the only possible way to let users choose
>> whichever indentation depth they want while preserving the continuation
>> alignment. What's not to like about that? Especially if you think a
>> horizontal tab can be any size at all, you should be all agog.
> 
> However, nobody ever gets that right, because they don't understand
> what you mean by indentation level. For most code that people write,
> indentation whitespace overlaps with non-whitespace (from the
> previous line). Therefore, the spaces used for continuation alignment
> with the previous line are left 'sitting on shaky ground'. For
> instance, consider this fine piece of code, given by lines 609-612 in
> builtin-log.c. If you're viewing this code with a monospace font and
> HT set to 8 columns, then the tab->spaces expansion should give the
> following result (monospace font required to view this properly):
> 
> static void make_cover_letter(struct rev_info *rev, int use_stdout,
>                               int numbered, int numbered_files,
>                               struct commit *origin,
>                               int nr, struct commit **list, struct commit *head)
> 
> Beautiful, isn't it?
> 
> In this case, we're at indentation level ---> 0 <---, and this means
> that to form the continuation alignment, 0 tabs should be used
> followed by however many spaces are needed to achieve the alignment.
> However, whoever wrote that code actually used indentation level 3:
> 
> <HT><HT><HT><SP><SP><SP><SP><SP><SP>
> 

> The problem is that variable-width characters (HTs) are being aligned
> with fixed-width characters. For shame!
> 
> To be explicit, if the HT width is set to 4, the result would be
> (after HT->spaces expansion):
> 
> static void make_cover_letter(struct rev_info *rev, int use_stdout,
>                   int numbered, int numbered_files,
>                   struct commit *origin,
>                   int nr, struct commit **list, struct commit *head)
> 
> Clearly, this is never a problem if you declare HTs to be fixed-width
> (which, I believe, Linus did do: 8 columns per HT), or if you can
> remember that HTs should never be used to align against non-HTs.
> 

> What I like to do is provide a more regular structure that removes the
> juxtaposition of indentation and alignment whitespace. Basically, HTs
> and spaces should never be contiguous, and the first use of a non-HT
> prohibits HTs from being used anywhere further down the line. Also,
> the structure of the code should facilitate identation levels:
> 
> static void make_cover_letter
> (
> 	/* These are all at indentation level 1 */
> 
> 	struct rev_info* rev            ,
> 	int              use_stdout     ,
> 	int              numbered       ,
> 	int              numbered_files ,
> 	struct commit*   origin         ,
> 	int              nr             ,
> 	struct commit**  list           ,
> 	struct commit*   head
> )
> {
> 	/* Code at indentation level 1 */
> }
> 
> Yeah, yeah, I know it's crazy, but it makes code wildly readable---to me.
>