git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Hudec <bulb@ucw.cz>
To: Jonathan del Strother <maillist@steelskies.com>
Cc: Paul Mackerras <paulus@samba.org>,
	"Shawn O. Pearce" <spearce@spearce.org>,
	git@vger.kernel.org
Subject: Re: gitk patch collection pull request
Date: Sat, 20 Oct 2007 17:32:16 +0200	[thread overview]
Message-ID: <20071020153216.GD19521@efreet.light.src> (raw)
In-Reply-To: <B3349B61-995B-42D0-B777-CEA618943848@steelskies.com>

[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]

On Sat, Oct 20, 2007 at 14:00:20 +0100, Jonathan del Strother wrote:
>
> On 20 Oct 2007, at 12:46, Paul Mackerras wrote:
>
>> Jonathan del Strother writes:
>>
>>> In my defense, most of that file is space indented, and the places
>>
>> Only the lines that are indented 1 level start with spaces.  Any line
>> that is indented 2 or more levels should start with a tab.
>
>>> It seems to have the whole 'tabs for code
>>> indentation, with space for alignment' rule back-to-front.
>>
>> I don't recall signing up to that rule. :)  I use 4-column indentation
>> and 8-column tabs, and my editor (emacs) handles it all automatically
>> for me.
>
>
> Ugh...  I don't usually get involved in tab/space wars, but I'm curious... 
> why on earth would you choose this style?

Because that's default behaviour of both emacs and vi when you set
indentation different from tabstop. Actually most of GNU software, whether it
uses the GNU standard indent of 2, or more, uses tabs for any indents
over 8. Probably even most unix software uses this.

Actually, even if the indent is 8, function arguments are often aligned under
the open parenthesis and a tabs + spaces combination is normally used for
that as well (because, again, that's what most editors will by default do!).

> With space indentation you can make sure that everyone sees the indentation 
> as it was intended.  With tab indentation, you save space, add semantic 
> meaning, and let people control how wide they want their indents to appear. 
>  This approach seems to take the worst parts of each and combine them.  
> What's the benefit?

Tab stops are every 8 characters. No more, no less. Ever. This makes the text
with whatever formating you want the shortest.

> I appreciate I'm not going to convert you - this is an honest question.
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-10-20 15:32 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-19  5:28 gitk patch collection pull request Shawn O. Pearce
2007-10-19  7:25 ` [PATCH resend again] gitk: Do not pick up file names of "copy from" lines Johannes Sixt
2007-10-19  7:32   ` Shawn O. Pearce
2007-10-19  8:05     ` Johannes Sixt
2007-10-19  8:14       ` Shawn O. Pearce
2007-10-19 11:05 ` gitk patch collection pull request Paul Mackerras
2007-10-20  3:10   ` Shawn O. Pearce
2007-10-20 11:12   ` Jonathan del Strother
2007-10-20 11:46     ` Paul Mackerras
2007-10-20 13:00       ` Jonathan del Strother
2007-10-20 15:32         ` Jan Hudec [this message]
2007-10-19 13:44 ` [PATCH-resent] gitk: fix in procedure drawcommits Michele Ballabio
2007-10-20 10:16   ` Paul Mackerras
2007-10-20 16:02     ` Michele Ballabio
2007-10-20 18:35       ` Jan Hudec
2007-10-21  3:01       ` Paul Mackerras
2007-10-21 12:12       ` Rocco Rutte
2007-10-19 19:31 ` gitk patch collection pull request Linus Torvalds
2007-10-20  4:45   ` Paul Mackerras
2007-10-20  4:51     ` Linus Torvalds
2007-10-23  0:20       ` Paul Mackerras
2007-10-23 19:17         ` Linus Torvalds
2007-10-23 23:37           ` Paul Mackerras
2007-10-23 23:51             ` Linus Torvalds
2007-10-24  0:17               ` Paul Mackerras

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=20071020153216.GD19521@efreet.light.src \
    --to=bulb@ucw.cz \
    --cc=git@vger.kernel.org \
    --cc=maillist@steelskies.com \
    --cc=paulus@samba.org \
    --cc=spearce@spearce.org \
    /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).