bug#6617: linux kernel C style (fwd)

bug#6617: linux kernel C style (fwd)

[Dimitrios Apostolou]

Hi, I sent the following to help-gnu-emacs and got no reply, maybe this 
list is more relevant.

---------- Forwarded message ----------
Date: Thu, 8 Jul 2010 21:56:09 +0300 (EEST)
From: Dimitrios Apostolou <jimis@gmx.net>
To: help-gnu-emacs@gnu.org
Subject: linux kernel C style

Hello list,

is the "linux" c-style supposed to be compliant to the linux kernel style 
guidelines? I just realised that all this time emacs was indenting my code 
slightly wrong, specifically the use of spaces is forbidden, even when 
continuing the argument list of a function.

I use the following lines in my .emacs, taken from Documentation/CodingStyle of 
the kernel tree. Perhaps they should be added to "linux" style?


(defun c-lineup-arglist-tabs-only (ignored)
    "Line up argument lists by tabs, not spaces"
    (let* ((anchor (c-langelem-pos c-syntactic-element))
 	  (column (c-langelem-2nd-pos c-syntactic-element))
 	  (offset (- (1+ column) anchor))
 	  (steps (floor offset c-basic-offset)))
      (* (max steps 1)
         c-basic-offset)))

;; Add kernel style
(c-add-style
   "linux-tabs-only"
   '("linux" (c-offsets-alist
 	     (arglist-cont-nonempty
 	      c-lineup-gcc-asm-reg
 	      c-lineup-arglist-tabs-only))))

(custom-set-variables
  '(c-default-style "linux-tabs-only")
)


Thanks,
Dimitris

bug#6617: linux kernel C style (fwd)

[Dan Nicolaescu]

Dimitrios Apostolou <jimis@gmx.net> writes:

> Hi, I sent the following to help-gnu-emacs and got no reply, maybe
> this list is more relevant.
>
> ---------- Forwarded message ----------
> Date: Thu, 8 Jul 2010 21:56:09 +0300 (EEST)
> From: Dimitrios Apostolou <jimis@gmx.net>
> To: help-gnu-emacs@gnu.org
> Subject: linux kernel C style
>
> Hello list,
>
> is the "linux" c-style supposed to be compliant to the linux kernel
> style guidelines? I just realised that all this time emacs was
> indenting my code slightly wrong, specifically the use of spaces is
> forbidden, even when continuing the argument list of a function.

Is that really the case?  Is this requirement documented anywhere?
Looking at a random file in the linux-2.6.34.1 kernel: kernel/sched.c
one can see:

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)
{ 
[snip]

The arguments starting from sd_shares are indented using a few tabs
followed by a few spaces.
The above is not the only occurrence, there are many others in the same file.


Another point: to enforce the use of the correct style, a file called
.dir-locals.el should be placed at the top level of the kernel tree
with the following [completely untested] contents:

((c-mode . ((c-file-style . "linux")
            (tab-width . 8)
            (indent-tabs-mode . t))))

With this users of emacs-23+ will get the correct settings for editing
the kernel by default.

bug#6617: linux kernel C style (fwd)

[Dimitrios Apostolou]

On Tue, 13 Jul 2010, Dan Nicolaescu wrote:
> Dimitrios Apostolou <jimis@gmx.net> writes:
>
>> Hi, I sent the following to help-gnu-emacs and got no reply, maybe
>> this list is more relevant.
>>
>> ---------- Forwarded message ----------
>> Date: Thu, 8 Jul 2010 21:56:09 +0300 (EEST)
>> From: Dimitrios Apostolou <jimis@gmx.net>
>> To: help-gnu-emacs@gnu.org
>> Subject: linux kernel C style
>>
>> Hello list,
>>
>> is the "linux" c-style supposed to be compliant to the linux kernel
>> style guidelines? I just realised that all this time emacs was
>> indenting my code slightly wrong, specifically the use of spaces is
>> forbidden, even when continuing the argument list of a function.
>
> Is that really the case?  Is this requirement documented anywhere?

In the file Documentation/CodingStyle search for "emacs". Warning: the 
language is a bit toxic for emacs devs/users.

There is also another point which is not clear but says the following:

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.


It is then followed by an example which is is indented only with tabs.


> Looking at a random file in the linux-2.6.34.1 kernel: kernel/sched.c 
> one can see:
>
> 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)
> {
> [snip]
>
> The arguments starting from sd_shares are indented using a few tabs
> followed by a few spaces.
> The above is not the only occurrence, there are many others in the same file.

My guess is that those are inconsistencies caused by the current "linux" 
style in emacs, but perhaps this should be posted to LKML to verify.

>
>
> Another point: to enforce the use of the correct style, a file called
> .dir-locals.el should be placed at the top level of the kernel tree
> with the following [completely untested] contents:
>
> ((c-mode . ((c-file-style . "linux")
>            (tab-width . 8)
>            (indent-tabs-mode . t))))
>
> With this users of emacs-23+ will get the correct settings for editing
> the kernel by default.
>
>



Thanks,
Dimitris

bug#6617: linux kernel C style (fwd)

[Dan Nicolaescu]

Dimitrios Apostolou <jimis@gmx.net> writes:

> On Tue, 13 Jul 2010, Dan Nicolaescu wrote:
>> Dimitrios Apostolou <jimis@gmx.net> writes:
>>
>>> Hi, I sent the following to help-gnu-emacs and got no reply, maybe
>>> this list is more relevant.
>>>
>>> ---------- Forwarded message ----------
>>> Date: Thu, 8 Jul 2010 21:56:09 +0300 (EEST)
>>> From: Dimitrios Apostolou <jimis@gmx.net>
>>> To: help-gnu-emacs@gnu.org
>>> Subject: linux kernel C style
>>>
>>> Hello list,
>>>
>>> is the "linux" c-style supposed to be compliant to the linux kernel
>>> style guidelines? I just realised that all this time emacs was
>>> indenting my code slightly wrong, specifically the use of spaces is
>>> forbidden, even when continuing the argument list of a function.
>>
>> Is that really the case?  Is this requirement documented anywhere?
>
> In the file Documentation/CodingStyle search for "emacs". Warning: the
> language is a bit toxic for emacs devs/users.

There's code there that seems to do what you stated, but there seems
to be no text that actually describes that...

> There is also another point which is not clear but says the following:
>
> 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.
>
>
> It is then followed by an example which is is indented only with tabs.
>
>
>> Looking at a random file in the linux-2.6.34.1 kernel:
>> kernel/sched.c one can see:
>>
>> 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)
>> {
>> [snip]
>>
>> The arguments starting from sd_shares are indented using a few tabs
>> followed by a few spaces.
>> The above is not the only occurrence, there are many others in the same file.
>
> My guess is that those are inconsistencies caused by the current
> "linux" style in emacs, but perhaps this should be posted to LKML to
> verify.

Please do that and report the conclusion here.

>> Another point: to enforce the use of the correct style, a file called
>> .dir-locals.el should be placed at the top level of the kernel tree
>> with the following [completely untested] contents:
>>
>> ((c-mode . ((c-file-style . "linux")
>>            (tab-width . 8)
>>            (indent-tabs-mode . t))))
>>
>> With this users of emacs-23+ will get the correct settings for editing
>> the kernel by default.
>>
>>
>
>
>
> Thanks,
> Dimitris

bug#6617: linux kernel C style (fwd)

[Lars Ingebrigtsen]

Dan Nicolaescu <dann@gnu.org> writes:

> 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.
>
> It is then followed by an example which is is indented only with tabs.
>
>> Looking at a random file in the linux-2.6.34.1 kernel:
>> kernel/sched.c one can see:
>>
>> 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)
>> {

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

It still seems to be the case that the "linux" style indents using both
tabs and spaces in Emacs 28.  I don't know what the Linux kernel style
is these days, but the suggestion in this bug report is to add a
tab-only variant.  Alan, do you have any comments about this?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#6617: linux kernel C style (fwd)

[Sean Whitton]

Hello,

On Wed 08 Sep 2021 at 10:40AM +02, Lars Ingebrigtsen wrote:

> Dan Nicolaescu <dann@gnu.org> writes:
>
>> 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.
>>
>> It is then followed by an example which is is indented only with tabs.
>>
>>> Looking at a random file in the linux-2.6.34.1 kernel:
>>> kernel/sched.c one can see:
>>>
>>> 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)
>>> {
>
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
>
> It still seems to be the case that the "linux" style indents using both
> tabs and spaces in Emacs 28.  I don't know what the Linux kernel style
> is these days, but the suggestion in this bug report is to add a
> tab-only variant.  Alan, do you have any comments about this?

The Linux kernel style is tabs only.  I think that Emacs DTRT if
indent-tabs-mode is t.  So, currently I have this fix in my init file:

    (c-add-style "linux-tabs" '("linux" (indent-tabs-mode . t)))
    (setq c-default-style "linux-tabs")

-- 
Sean Whitton

bug#6617: linux kernel C style (fwd)

[Lars Ingebrigtsen]

Sean Whitton <spwhitton@spwhitton.name> writes:

> The Linux kernel style is tabs only.  I think that Emacs DTRT if
> indent-tabs-mode is t.  So, currently I have this fix in my init file:
>
>     (c-add-style "linux-tabs" '("linux" (indent-tabs-mode . t)))
>     (setq c-default-style "linux-tabs")

Right.  Alan, would it make sense to add this style to c-mode?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#6617: linux kernel C style (fwd)

[Sean Whitton]

Hello,

On Thu 09 Sep 2021 at 04:00PM +02, Lars Ingebrigtsen wrote:

> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> The Linux kernel style is tabs only.  I think that Emacs DTRT if
>> indent-tabs-mode is t.  So, currently I have this fix in my init file:
>>
>>     (c-add-style "linux-tabs" '("linux" (indent-tabs-mode . t)))
>>     (setq c-default-style "linux-tabs")
>
> Right.  Alan, would it make sense to add this style to c-mode?

Were you thinking it would be too much of a compat break to just edit
the linux style to include setting indent-tabs-mode?  I think that would
be a lot more useful.  Anyone who actually wants the Linux kernel's
style would want (what I've called) linux-tabs.

-- 
Sean Whitton

bug#6617: linux kernel C style (fwd)

[Alan Mackenzie]

Hello, Sean.

On Mon, Apr 18, 2022 at 11:30:04 -0700, Sean Whitton wrote:
> Hello,

> On Thu 09 Sep 2021 at 04:00PM +02, Lars Ingebrigtsen wrote:

> > Sean Whitton <spwhitton@spwhitton.name> writes:

> >> The Linux kernel style is tabs only.  I think that Emacs DTRT if
> >> indent-tabs-mode is t.  So, currently I have this fix in my init file:

> >>     (c-add-style "linux-tabs" '("linux" (indent-tabs-mode . t)))
> >>     (setq c-default-style "linux-tabs")

> > Right.  Alan, would it make sense to add this style to c-mode?

> Were you thinking it would be too much of a compat break to just edit
> the linux style to include setting indent-tabs-mode?  I think that would
> be a lot more useful.  Anyone who actually wants the Linux kernel's
> style would want (what I've called) linux-tabs.

After a bit of thought, I agree with you.  I think here it is better
just to add the setting of indent-tabs-mode to the "linux" style.  Most
users of "linux" will have that variable set to t one way or another,
and so won't notice.

There will be a few users using the style for non-Linux projects, who
will be used to indent-tabs-mode being nil.  That is just unfortunate.
I think the balance of benefits and problems comes down on the side of
this abrupt change.

I intend to apply the following patch to cc-styles.el soon.  If you want
to test it you're very welcome, but please note that since it changes a
variable, the amended CC Mode should be the first CC Mode you load in
the Emacs session.  (Otherwise, you'll need to do fancy things with
`makunbound' before loading the new CC Mode.)



diff -r 8fd64e3084ac cc-styles.el
--- a/cc-styles.el	Sat Apr 23 19:17:52 2022 +0000
+++ b/cc-styles.el	Sun Apr 24 14:36:46 2022 +0000
@@ -187,6 +187,7 @@
 			 (inclass              . +)
 			 (inline-open          . 0))))
     ("linux"
+     (indent-tabs-mode . t)
      (c-basic-offset  . 8)
      (c-comment-only-line-offset . 0)
      (c-hanging-braces-alist . ((brace-list-open)


> -- 
> Sean Whitton

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#6617: linux kernel C style (fwd)

[Sean Whitton]

Hello Alan,

On Sun 24 Apr 2022 at 02:50PM GMT, Alan Mackenzie wrote:

> After a bit of thought, I agree with you.  I think here it is better
> just to add the setting of indent-tabs-mode to the "linux" style.  Most
> users of "linux" will have that variable set to t one way or another,
> and so won't notice.
>
> There will be a few users using the style for non-Linux projects, who
> will be used to indent-tabs-mode being nil.  That is just unfortunate.
> I think the balance of benefits and problems comes down on the side of
> this abrupt change.

Right.

> I intend to apply the following patch to cc-styles.el soon.  If you
> want to test it you're very welcome, but please note that since it
> changes a variable, the amended CC Mode should be the first CC Mode
> you load in the Emacs session.  (Otherwise, you'll need to do fancy
> things with `makunbound' before loading the new CC Mode.)

I'm not in the middle of any C projects using the Linux style atm, so I
don't think I'll be able to test, but your patch looks basically
equivalent to the "linux-tabs" thing I was doing, so probably doesn't
need a lot of testing.  Thanks for thinking this one over!

-- 
Sean Whitton

bug#6617: linux kernel C style (fwd)

[Alan Mackenzie]

Hello, everybody.

On Sun, Apr 24, 2022 at 14:16:23 -0700, Sean Whitton wrote:
> Hello Alan,

> On Sun 24 Apr 2022 at 02:50PM GMT, Alan Mackenzie wrote:

> > After a bit of thought, I agree with you.  I think here it is better
> > just to add the setting of indent-tabs-mode to the "linux" style.  Most
> > users of "linux" will have that variable set to t one way or another,
> > and so won't notice.

> > There will be a few users using the style for non-Linux projects, who
> > will be used to indent-tabs-mode being nil.  That is just unfortunate.
> > I think the balance of benefits and problems comes down on the side of
> > this abrupt change.

> Right.

> > I intend to apply the following patch to cc-styles.el soon.  If you
> > want to test it you're very welcome, but please note that since it
> > changes a variable, the amended CC Mode should be the first CC Mode
> > you load in the Emacs session.  (Otherwise, you'll need to do fancy
> > things with `makunbound' before loading the new CC Mode.)

> I'm not in the middle of any C projects using the Linux style atm, so I
> don't think I'll be able to test, but your patch looks basically
> equivalent to the "linux-tabs" thing I was doing, so probably doesn't
> need a lot of testing.  Thanks for thinking this one over!

I've now committed the change to cc-styles.el, and am closing the bug
with this post.

> -- 
> Sean Whitton

-- 
Alan Mackenzie (Nuremberg, Germany).