git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Ericsson <ae@op5.se>
To: Michael Witten <mfwitten@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH RFC3 09/13] send-email: Remove horrible mix of tabs and spaces
Date: Tue, 14 Apr 2009 09:17:45 +0200	[thread overview]
Message-ID: <49E43899.7070804@op5.se> (raw)
In-Reply-To: <7vws9n92q3.fsf@gitster.siamese.dyndns.org>

Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
> 
>> 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.
> 
> Sure, it will look aligned with whatever width of HT ">":
> 
> 	>>if (this is a looong
>         >>....expression that is alighed) {
>         >>>statement1;
>         >>>statement2;
>         >>}
> 
> but it is *only true* if your SP "." and everything else is of the same
> width.
> 
> People seem to repeat that without realizing what they are saying, but I
> find the assumption the argument is based on quite bogus.  Why do people
> think it is only sane to assume flexible HT width but still monospaced
> font whose SP, l and w are all of the same width?
> 

Because 99% of all editors designed for programming use a fixed-width font
by default for precisely that reason, and all others can be set to display
fixed-width fonts without losing much (if any) readability, but indentation
comes in 2*$number_of_programmers variations.


> You either forget about the alignment (there is no such thing---suck it
> up), or use time honored HT=8 and monospace convention.
> 

Or you use "indent with tabs, align with spaces" and let those who use a
word processor for programming go hang. It's quite common actually. Or
you use some own homecooked style of indentation that's quite obvious
*to you* Either way, a project's founding father always sets the style,
and those who contribute get to either follow it or provide some pretty
strong argument to change it (a lot better than:

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

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

  reply	other threads:[~2009-04-14  7:19 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-13 18:23 [PATCH RFC3 INTRO] I hope this will do it! Michael Witten
2009-04-13 18:23 ` [PATCH RFC3 01/13] Docs: send-email: Put options back into alphabetical order Michael Witten
2009-04-13 18:23   ` [PATCH RFC3 02/13] Docs: send-email: Refer to CONFIGURATION section for sendemail.multiedit Michael Witten
2009-04-13 18:23     ` [PATCH RFC3 03/13] Docs: send-email: Remove superfluous information in CONFIGURATION Michael Witten
2009-04-13 18:23       ` [PATCH RFC3 04/13] Docs: send-email: --smtp-server-port can take symbolic ports Michael Witten
2009-04-13 18:23         ` [PATCH RFC3 05/13] send-email: Cleanup the usage text and docs a bit Michael Witten
2009-04-13 18:23           ` [PATCH RFC3 06/13] send-email: Handle "GIT:" rather than "GIT: " during --compose Michael Witten
2009-04-13 18:23             ` [PATCH RFC3 07/13] send-email: 'References:' should only reference what is sent Michael Witten
2009-04-13 18:23               ` [PATCH RFC3 08/13] send-email: Remove superfluous `my $editor = ...' Michael Witten
2009-04-13 18:23                 ` [PATCH RFC3 09/13] send-email: Remove horrible mix of tabs and spaces Michael Witten
2009-04-13 18:23                   ` [PATCH RFC3 10/13] send-email: Add --sleep for email throttling Michael Witten
2009-04-13 18:23                     ` [PATCH RFC3 11/13] send-email: Minor cleanup of $smtp_server usage and send_message() Michael Witten
2009-04-13 18:23                       ` [PATCH RFC3 12/13] send-email: --compose takes optional argument to existing file Michael Witten
2009-04-13 18:23                         ` [PATCH RFC3 13/13] send-email: --compose always includes a 'GIT: ' prefixed list of patch subjects Michael Witten
2009-04-13 20:55                   ` [PATCH RFC3 09/13] send-email: Remove horrible mix of tabs and spaces Junio C Hamano
2009-04-13 22:49                     ` Michael Witten
2009-04-14  5:31                       ` Andreas Ericsson
2009-04-14  6:19                         ` Junio C Hamano
2009-04-14  7:17                           ` Andreas Ericsson [this message]
2009-04-14  7:03                         ` Michael Witten
2009-04-14  7:38                           ` Andreas Ericsson
2009-04-13 23:39                 ` [PATCH RFC3 08/13] send-email: Remove superfluous `my $editor = ...' Stephen Boyd
2009-04-14  0:41                   ` Michael Witten
2009-04-14  0:43                     ` Michael Witten
2009-04-14  6:16                   ` Björn Steinbrink
2009-04-14  8:51                     ` Junio C Hamano
2009-04-13 20:51           ` [PATCH RFC3 05/13] send-email: Cleanup the usage text and docs a bit Junio C Hamano
2009-04-13 22:42             ` Michael Witten
2009-04-14  5:39               ` Junio C Hamano
2009-04-14  6:00                 ` Michael Witten
2009-04-14  6:46                   ` Junio C Hamano
2009-04-14  7:15                     ` Michael Witten
2009-04-13 20:45       ` [PATCH RFC3 03/13] Docs: send-email: Remove superfluous information in CONFIGURATION Junio C Hamano
2009-04-13 22:30         ` Michael Witten
2009-04-13 18:45 ` [PATCH RFC3 INTRO] I hope this will do it! Michael Witten
2009-04-14  9:02 ` Junio C Hamano
2009-04-14 16:26   ` Michael Witten
2009-04-14 18:47     ` Junio C Hamano
2009-04-14 18:50       ` Michael Witten

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49E43899.7070804@op5.se \
    --to=ae@op5.se \
    --cc=git@vger.kernel.org \
    --cc=mfwitten@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).