linux-kernel - Re: [PATCH v2] editorconfig: Add automatic editor configuration file

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK7LNAQ+M5Cn84tkEAiLDoyaKmrG-cFOyUjPgFC2+ksDGHn3vQ@mail.gmail.com>
Date:   Thu, 25 Mar 2021 16:00:37 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:     Jonathan Corbet <corbet@....net>, Danny Lin <danny@...ag0n.dev>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andy Whitcroft <apw@...onical.com>,
        Joe Perches <joe@...ches.com>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] editorconfig: Add automatic editor configuration file

On Wed, Mar 24, 2021 at 8:01 PM Rasmus Villemoes
<linux@...musvillemoes.dk> wrote:
>
> On 03/07/2020 14.29, Jonathan Corbet wrote:
>
> [doing a bit of necromancy here]
>
> > On Fri,  3 Jul 2020 00:31:43 -0700
> > Danny Lin <danny@...ag0n.dev> wrote:
> >
> >> EditorConfig is a standard for defining basic editor configuration in
> >> projects. There is support available for 47 code editors as of writing,
> >> including both built-in and extension support. Many notable projects
> >> have adopted the standard already, including zsh, htop, and qemu.
> >>
> >> While this isn't a full-fledged C code style specifier, it does set some
> >> basic ground rules that make it more convenient for contributors to use
> >> any editor of their choice and not have to worry about indentation, line
> >> endings, encoding, final newlines, etc. This should make it
> >> significantly easier to conform to the kernel's general code style when
> >> used in combination with clang-format.
> >>
> >> For more information, check the official EditorConfig website:
> >> https://editorconfig.org/
> >>
> >> Signed-off-by: Danny Lin <danny@...ag0n.dev>
> >> ---
> >
> > So I worry a bit that not everybody will welcome the addition of a dotfile
> > that may be magically interpreted by their editor.
>
> I would suppose that one would have to enable editorconfig support
> explicitly in one's editor, so this would have no effect for people that
> haven't done so (though there are almost certainly exceptions).
>
> > I also worry that the
> > file itself could become a battleground for people wanting to argue about
> > style issues.
>
> I don't think so, not any more than the coding-style document is, and
> that seems to be pretty solid (but as doc maintainer, you'd know better).
>
> >
> > Perhaps I worry a bit too much...?
>
> As someone who regularly needs to submit patches to random upstream
> projects to fix bugs or implement minor features, I for one would really
> welcome more widespread use of editorconfig. While I mostly work with
> the linux kernel (and other projects using the same C style), so my
> default C style setting is "linux", even for the kernel this would be
> helpful to me when I poke around in none-C files (shell scripts, for
> example).
>
> Rasmus


Just from my curiosity, I just checked the behavior
when the language is specified by a shebang line.

For example, scripts/diffconfig has no file suffix,
but specifies '#!/usr/bin/env python3'
at the very top line.
This is sensible for tools that interface to users.
Users have no interest in which language is used
internally.


As far as I test this patch on Emacs, it follows the rule
of [*] rather than [*.{pl,pm,py,tc,json,tc}].

This is the correct behavior but not what we want in general.

I do not mean I am negative to this patch.
Rather, I very much like this patch, but I just
wondered how this case could be handled.

I found this:
https://github.com/editorconfig/editorconfig/issues/404
I did not read through it, though.


--
Best Regards
Masahiro Yamada