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.
next prev parent 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).