Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [git commit] tstools: GitHub migration
Date: Tue, 20 Oct 2015 18:35:17 +0200	[thread overview]
Message-ID: <20151020163517.GB3738@free.fr> (raw)
In-Reply-To: <56265B25.8070900@imgtec.com>

Vicente, All,

On 2015-10-20 16:17 +0100, Vicente Olivert Riera spake thusly:
> On 10/20/2015 04:14 PM, Thomas Petazzoni wrote:
> > On Tue, 20 Oct 2015 16:33:07 +0200, Peter Korsgaard wrote:
> >> -	  This is a set of cross-platform command line tools for
> >> -	  working with MPEG data
> >> +	  This is a set of cross-platform command line tools for working with
> >> +	  MPEG data.
> > 
> > This clearly doesn't fit in 72 characters now, except if you count tab
> > as one character of course. emacs says that the long line here is now
> > 77 characters long.
> 
> Yes, I count the tab as 1 character. Shouldn't I?
> 
> For me, the tab is 1 character. Then you can set your text editor to
> display the tabs as you want. You can display them as 1 space, 2, 3, 4...

A TAB is one byte, but N characters. And in buildroot, we use N=8.

Note: I hate TABs. TABs are so 70s. Besides, since, as you said, the
width of TABs varies very wildely between machines (due to personal
tastes), it means that TABs can not reliably be used to provide a
"beautiful" layout that is reprpducible everywhere as-is; various
editors will always break that nice layout.

Besides, using 8-char-wide TABs means indentation very quickly limits
the amount of space to write code (80-char-wide lines are close to the
optimum width for human reading).

Also, it is very hard to configure one's editor, sicne coding rules vary
between projects, some requiring leading TABs, 4- or 8- (or even 2!)
char wide, while others require leading spaces...

There is today *no* reason to use leading TABs; any sane editor will
happily insert how-many space you want when pressing TAB (heck, I guess
even emacs is capable of that ;-] ).

But since Buildroot has decided to go with leading TABS, and 8-char-wide
TABs, I abide to that rule! ;-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2015-10-20 16:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-20 14:33 [Buildroot] [git commit] tstools: GitHub migration Peter Korsgaard
2015-10-20 15:14 ` Thomas Petazzoni
2015-10-20 15:17   ` Vicente Olivert Riera
2015-10-20 16:35     ` Yann E. MORIN [this message]
2015-10-20 18:11       ` Peter Korsgaard
2015-10-20 18:33         ` Yann E. MORIN

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=20151020163517.GB3738@free.fr \
    --to=yann.morin.1998@free.fr \
    --cc=buildroot@busybox.net \
    /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