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

[Danny Lin]

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@xxxxxxxxx> wrote:
>>
>> Hi Íñigo,
>>
>> On Tue, Apr 4, 2023 at 9:55 AM Íñigo Huguet <ihuguet@xxxxxxxxxx> 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@xxxxxxxxxxx/
>> 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