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

[Íñigo Huguet]

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.

> 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