all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dan Nicolaescu <dann@gnu.org>
To: Dimitrios Apostolou <jimis@gmx.net>
Cc: 6617@debbugs.gnu.org
Subject: bug#6617: linux kernel C style (fwd)
Date: Tue, 13 Jul 2010 08:51:30 -0400	[thread overview]
Message-ID: <yxqzkxvo88d.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <alpine.LNX.2.00.1007131202090.1500@localhost.localdomain> (Dimitrios Apostolou's message of "Tue\, 13 Jul 2010 12\:17\:38 +0300 \(EEST\)")

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





  reply	other threads:[~2010-07-13 12:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-12 10:08 bug#6617: linux kernel C style (fwd) Dimitrios Apostolou
2010-07-13  8:51 ` Dan Nicolaescu
2010-07-13  9:17   ` Dimitrios Apostolou
2010-07-13 12:51     ` Dan Nicolaescu [this message]
2021-09-08  8:40   ` Lars Ingebrigtsen
2021-09-08 18:29     ` Sean Whitton
2021-09-09 14:00       ` Lars Ingebrigtsen
2022-04-18 18:30         ` Sean Whitton
2022-04-24 14:50           ` Alan Mackenzie
2022-04-24 21:16             ` Sean Whitton
2022-04-27 19:17               ` Alan Mackenzie

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=yxqzkxvo88d.fsf@fencepost.gnu.org \
    --to=dann@gnu.org \
    --cc=6617@debbugs.gnu.org \
    --cc=jimis@gmx.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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.