linux-kernel - Re: [PATCH v2] Add .editorconfig file for basic formatting

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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 04 Apr 2023 08:37:43 -0700
From:   "Danny Lin" <danny@...ag0n.dev>
To:     Íñigo Huguet <ihuguet@...hat.com>,
        "Miguel Ojeda" <miguel.ojeda.sandonis@...il.com>
Cc:     ojeda@...nel.org, masahiroy@...nel.org, jgg@...dia.com,
        mic@...ikod.net, linux-kernel@...r.kernel.org,
        "Jonathan Corbet" <corbet@....net>,
        "Joe Perches" <joe@...ches.com>,
        "Rasmus Villemoes" <linux@...musvillemoes.dk>,
        "Matthew Wilcox" <willy@...radead.org>
Subject: Re: [PATCH v2] Add .editorconfig file for basic formatting

On Tue, Apr 04, 2023 at  4:37 AM, Íñigo Huguet wrote:
> On Tue, Apr 4, 2023 at 11:51 AM Miguel Ojeda
> <miguel.ojeda.sandonis@...il.com> wrote:
>>
>> Hi Íñigo,
>>
>> On Tue, Apr 4, 2023 at 9:55 AM Íñigo Huguet <ihuguet@...hat.com> wrote:
>> >
>> > EditorConfig is a specification to define the most basic code formatting
>> > stuff, and it's supported by many editors and IDEs, either directly or
>> > via plugins, including VSCode/VSCodium, Vim, emacs and more.
>>
>> Please see https://lore.kernel.org/lkml/20200703073143.423557-1-danny@kdrag0n.dev/
>> for a previous patch & discussion, as well as commit fa60ce2cb450
>> ("treewide: remove editor modelines and cruft") for a related cleanup.
>> Cc'ing those that gave some feedback back then.
>>
>> Danny's v2 patch has some extra extensions/languages it manages as
>> well as some docs, and yours handles things that one doesn't, like the
>> Rust files and `Makefile.*` cases. So it would be nice to get a
>> version that merges everything from both of you, likely as
>> co-developers.
>
> I will be happy to prepare the patch, as co-developers, if Danny agrees.

That's fine by me. Thanks for picking this back up!

>
>> It still remains important to see if somebody's workflow could break
>> due to this, especially for the catch-all section `[*]` and for
>> options like `trim_trailing_whitespace` which can actually break
>> things like patch files as you note in the changelog. Perhaps landing
>> it in linux-next for an extended period of time (e.g. a few kernel
>> cycles) is one way to find out, or we could start without the
>> "dangerous" options. What do others think?
>
> I can move everything from [*] to the extension based sections
> (*.{c,h} and so on), so it is safer. It can only happen that someone
> notices that a weird file is not auto-formatted, and hopefully gives
> feedback to add it to .editorconfig.
>
> About the potential break of some workflows, and after reading the
> previous conversation, I don't think there is much else we can do. In
> any case, it won't be that harmful: using editorconfig is almost
> always opt-in, and if anyone has a problem, he will disable
> editorconfig to complete the changes and hopefully give feedback.
>
> If you think that it's better to keep it in linux-next for some time,
> it's fine, but I don't think it's necessary. As I say, I don't think
> it can be that much disturbing.
>
> Finally, about the files without extension but with a shebang,
> mentioned by Masahiro, it seems that they're seriously considering
> supporting tags based on language, like [[python]] and [[bash]], but
> nothing has been done yet, so, again, there's no much we can do. If
> someone frequently update specific files and want editorconfig
> formatting for them, their full paths can be added.
>
> Regards
>
>> By the way, for the next/merged version, in your side please keep
>> `!.editorconfig` sorted and in the other side please avoid the
>> duplicated `.tc` case (which I just noticed).
>>
>> Cheers,
>> Miguel
>>
>
>
> -- 
> Íñigo Huguet

Best,
Danny