Hello list,
according to Documentation/CodingStyle the "linux" style of emacs is
broken because it uses tabs+spaces when continuing the argument list of a
function on a new line. So I reported that as a bug to bug-gnu-emacs
(bug#6617).
However it's not clear if this is a bug of emacs or an inconsistency of
the linux kernel coding style. I can't find where exactly the usage *only*
of tabs is mandated, see for example the following quote:
> Statements longer than 80 columns will be broken into sensible
> chunks. Descendants are always substantially shorter than the parent
> and are placed substantially to the right. The same applies to
> function headers with a long argument list. Long strings are as well
> broken into shorter strings. The only exception to this is where
> exceeding 80 columns significantly increases readability and does not
> hide information.
Tabs are not mentioned anywhere, besides the specific part about emacs
which is so ironic that no emacs dev can read it fully. Moreover there are
many parts in the kernel that are aligned using both tabs and spaces.
Random example in the linux-2.6.34.1 kernel: kernel/sched.c
static void update_group_shares_cpu(struct task_group *tg, int cpu,
unsigned long sd_shares,
unsigned long sd_rq_weight,
unsigned long *usd_rq_weight)
{
So what do you think? Should the current emacs "linux" style be fixed, or
are spaces allowed?
Thanks,
Dimitris
On Tue, 13 Jul 2010 17:00:21 +0300 (EEST) Dimitrios Apostolou wrote:
> Hello list,
>
> according to Documentation/CodingStyle the "linux" style of emacs is
> broken because it uses tabs+spaces when continuing the argument list of a
> function on a new line. So I reported that as a bug to bug-gnu-emacs
> (bug#6617).
>
> However it's not clear if this is a bug of emacs or an inconsistency of
> the linux kernel coding style. I can't find where exactly the usage *only*
> of tabs is mandated, see for example the following quote:
>
>
> > Statements longer than 80 columns will be broken into sensible
> > chunks. Descendants are always substantially shorter than the parent
> > and are placed substantially to the right. The same applies to
> > function headers with a long argument list. Long strings are as well
> > broken into shorter strings. The only exception to this is where
> > exceeding 80 columns significantly increases readability and does not
> > hide information.
See CodingStyle, Chapter 1, Indentation:
"Outside of comments, documentation and except in Kconfig, spaces are never
used for indentation, and the above example is deliberately broken."
which to me means "spaces alone are never used (unless the indentation is less than
8 columns)".
> Tabs are not mentioned anywhere, besides the specific part about emacs
> which is so ironic that no emacs dev can read it fully. Moreover there are
> many parts in the kernel that are aligned using both tabs and spaces.
> Random example in the linux-2.6.34.1 kernel: kernel/sched.c
>
>
> static void update_group_shares_cpu(struct task_group *tg, int cpu,
> unsigned long sd_shares,
> unsigned long sd_rq_weight,
> unsigned long *usd_rq_weight)
> {
In the example above, some email software seems to have munged tabs
into spaces, or someone used copy-and-paste, which also translated
tabs into spaces. It should have been:
static void update_group_shares_cpu(struct task_group *tg, int cpu,
unsigned long sd_shares,
unsigned long sd_rq_weight,
unsigned long *usd_rq_weight)
{
which is a common usage model in the Linux kernel.
> So what do you think? Should the current emacs "linux" style be fixed, or
> are spaces allowed?
<tab(s)>+<less than 8 spaces> are often used for function parameter alignment,
as above. More than 7 spaces should not be used. I don't find the function
parameter alignment very important, so sometimes I just use tabs and no spaces
and omit the parameter alignment, but mostly what I do is match the current
existing style in the code that I am working on.
I'm not an emacs (O.S.) user, but I doubt that the emacs linux style needs
to be fixed.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Jul 13, 2010, at 6:19 PM, Randy Dunlap wrote:
>
> See CodingStyle, Chapter 1, Indentation:
>
> "Outside of comments, documentation and except in Kconfig, spaces are never
> used for indentation, and the above example is deliberately broken."
>
> which to me means "spaces alone are never used (unless the indentation is less than
> 8 columns)".
There is a huge amount of code --- including code which I submitted
back in the 0.12 days of Linux --- which uses spaces to align continuation
lines for function parameters, i.e.
static int foo(struct inode inode, struct file *file, int flags,
size_t len)
such that "struct" and "size_t" are aligned on the same column, and also so that:
unsigned int num = ((len + sizeof(struct foobaz) - 3) /
(4 + sizeof(struct foobaz)));
I've always read indentation as referring to indentation for the beginning of
code lines, but not to making function parameters or paraenthesis line
up. This is something which emacs does automatically, but vi does not.
People who are anal enough to worry about this sort of thing, in general,
IMHO, really should find better things to do. And if checkpatch.pl were to
be "improved" to start issue warnings about code not adhering to this
CodingStyle assertion, #1, you would find out how much code doesn't
adhere to this, and #2, I think a lot of people, including myself, would be
complaining vociferously and agitating to have that language removed
from CodingStyle as being an actively harmful and incorrect recommendation.
-- Ted
Hi,
On Wed, 14 Jul 2010, Theodore Tso wrote:
> I've always read indentation as referring to indentation for the beginning of
> code lines, but not to making function parameters or paraenthesis line
> up. This is something which emacs does automatically, but vi does not.
>
> People who are anal enough to worry about this sort of thing, in general,
> IMHO, really should find better things to do. And if checkpatch.pl were to
> be "improved" to start issue warnings about code not adhering to this
> CodingStyle assertion, #1, you would find out how much code doesn't
> adhere to this, and #2, I think a lot of people, including myself, would be
> complaining vociferously and agitating to have that language removed
> from CodingStyle as being an actively harmful and incorrect recommendation.
if two kernel developers agree that tabs-only alignment of arglists is not
necessary, then my guess is that the CodingStyle document is broken and
needs to be fixed. Quote from Documentation/CodingStyle:
That's OK, we all do. You've probably been told by your long-time
Unix user helper that "GNU emacs" automatically formats the C sources for
you, and you've noticed that yes, it does do that, but the defaults it
uses are less than desirable (in fact, they are worse than random typing -
an infinite number of monkeys typing into GNU emacs would never make a
good program).
So, you can either get rid of GNU emacs, or change it to use saner
values. To do the latter, you can stick the following in your .emacs
file:
If emacs' style is OK then why all this inflamatory talk is needed, and
why is a patch proposed? The only thing needed is to use the "linux"
c-style.
Thanks,
Dimitris
P.S. CC'd the author of latest emacs-related patch in CodingStyle
Dimitrios Apostolou <[email protected]> writes:
> static void update_group_shares_cpu(struct task_group *tg, int cpu,
> unsigned long sd_shares,
> unsigned long sd_rq_weight,
> unsigned long *usd_rq_weight)
> {
>From a technical POV the above should not have any tabs, the parameters
should be aligned with spaces only.
The tabs should be used for (syntactic) indentation only.
This way we can display the code correctly with any tab length.
--
Krzysztof Halasa
On Sat, 17 Jul 2010 11:21:03 +0200 Krzysztof Halasa wrote:
> Dimitrios Apostolou <[email protected]> writes:
>
> > static void update_group_shares_cpu(struct task_group *tg, int cpu,
> > unsigned long sd_shares,
> > unsigned long sd_rq_weight,
> > unsigned long *usd_rq_weight)
> > {
>
> From a technical POV the above should not have any tabs, the parameters
> should be aligned with spaces only.
fwiw, it seems that you agree with Ted.
> The tabs should be used for (syntactic) indentation only.
>
> This way we can display the code correctly with any tab length.
but we know what the tab length is. ;)
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
Randy Dunlap <[email protected]> writes:
> fwiw, it seems that you agree with Ted.
That's correct :-)
>> The tabs should be used for (syntactic) indentation only.
>> This way we can display the code correctly with any tab length.
>
> but we know what the tab length is. ;)
We have to, at least for now. Existing tools force it upon us.
But it would be nice if we could use any tab length.
--
Krzysztof Halasa
On Sat, Jul 17, 2010 at 06:51:46AM -0700, Randy Dunlap wrote:
> On Sat, 17 Jul 2010 11:21:03 +0200 Krzysztof Halasa wrote:
>
> > Dimitrios Apostolou <[email protected]> writes:
> >
> > > static void update_group_shares_cpu(struct task_group *tg, int cpu,
> > > unsigned long sd_shares,
> > > unsigned long sd_rq_weight,
> > > unsigned long *usd_rq_weight)
> > > {
> >
> > From a technical POV the above should not have any tabs, the parameters
> > should be aligned with spaces only.
>
> fwiw, it seems that you agree with Ted.
Actually, what my code use is tabs with a tab stop of 8 followed by
enough spaces (< 7) to align function parameters and to align
open/close parenthesis in C expression line wrap.
The main problem seems to be that Chapter 9 in
Documentation/CodingStyle is written by someone who feels that since
vi makes it easy to only align parameters using tabs, that everybody
should do it the same way as vi. I'm simply challenging Chapter 9 as
being canon. I certainly ignore it, and as a maintainer I tend to
accept either vi or emacs-style indentations with respect to
parameters and C expressions.
- Ted
On Sun, 18 Jul 2010, Ted Ts'o wrote:
> On Sat, Jul 17, 2010 at 06:51:46AM -0700, Randy Dunlap wrote:
>> On Sat, 17 Jul 2010 11:21:03 +0200 Krzysztof Halasa wrote:
>>
>>> Dimitrios Apostolou <[email protected]> writes:
>>>
>>>> static void update_group_shares_cpu(struct task_group *tg, int cpu,
>>>> unsigned long sd_shares,
>>>> unsigned long sd_rq_weight,
>>>> unsigned long *usd_rq_weight)
>>>> {
>>>
>>> From a technical POV the above should not have any tabs, the parameters
>>> should be aligned with spaces only.
>>
>> fwiw, it seems that you agree with Ted.
>
> Actually, what my code use is tabs with a tab stop of 8 followed by
> enough spaces (< 7) to align function parameters and to align
> open/close parenthesis in C expression line wrap.
FWIW that way will show the parameters unaligned to anyone using a
different tab length. There is one way to align such lines properly:
You indent with as many tabs as the previous line has and you use all
spaces (perhaps more than 8) afterwards, to align parameters where you
want them. In the example above that would use 0 tabs, all spaces...
Unfortunately this style is not the default to any editor I have seen,
even though it really makes code readable with any tab length. Even for
emacs you have to customize your config file:
http://www.emacswiki.org/emacs/SmartTabs
Dimitris
Ted Ts'o <[email protected]> writes:
> Actually, what my code use is tabs with a tab stop of 8 followed by
> enough spaces (< 7) to align function parameters and to align
> open/close parenthesis in C expression line wrap.
To be honest, I do precisely the same, though I think it's far from
perfect. It's just emacs which can't do better (or I don't know how to
make it do better).
> The main problem seems to be that Chapter 9 in
> Documentation/CodingStyle is written by someone who feels that since
> vi makes it easy to only align parameters using tabs, that everybody
> should do it the same way as vi. I'm simply challenging Chapter 9 as
> being canon. I certainly ignore it, and as a maintainer I tend to
> accept either vi or emacs-style indentations with respect to
> parameters and C expressions.
Fully agreed.
--
Krzysztof Halasa
On Sun, Jul 18, 2010 at 12:10:09PM +0300, Dimitrios Apostolou wrote:
>
> FWIW that way will show the parameters unaligned to anyone using a
> different tab length. There is one way to align such lines properly:
As Randy said, the One True Tab Stop Length is 8. I don't think
that's going to change anytime soon. You might as well complain that
things don't look right if you like to use a font with variable width
characters...
- Ted
On Sun, 2010-07-18 at 03:15 -0400, Ted Ts'o wrote:
> Actually, what my code use is tabs with a tab stop of 8 followed by
> enough spaces (< 7) to align function parameters and to align
> open/close parenthesis in C expression line wrap.
Yes, I also like and use this style.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
Ted Ts'o <[email protected]> writes:
> As Randy said, the One True Tab Stop Length is 8. I don't think
> that's going to change anytime soon.
I hope we will be able to eventually remove this limitation. There is
nothing technical in it, except deficiency of the editors.
Nice to see emacs can handle it.
--
Krzysztof Halasa