Subject: Re: [PATCH] editorconfig: add Makefiles to "text files"

From: Junio C Hamano <[email-masked]>
Date: Sat, 23 Mar 2024 10:36:01 -0700

Max Gautier <[email-masked]> writes:

>>  * Among the files we ship (i.e. "git ls-tree -r HEAD") and edit
>>    with editors that honor .editorconfig settings, are there any
>>    file that we do not want tab indentation other than *.py?
>
> $ git ls-tree -r HEAD | cut -f 2 | \
> ...
>       2 png
> ...

As I expected ;-) We do not have all that many kinds.  Some like
image files are not even meant to be edited as text and the usual
"editor"s people use to edit them are probably unaware of what we
write in the .editorconfig file.

> Not sure which one among those don't want the same tab-indent settings
> though.

That is the other important question.  What I was hoping to hear was
that other than Python there are not be any kind that are edited by
editorconfig-aware editors.  But that unfortunately is not what we
are hearing.

>>  * Does .editorconfig file allow possibly conflicting setting, with
>>    a reliable conflict resolution rules?
>
> Yeah it does: https://spec.editorconfig.org/#id8
> TL;DR:
> - from top to bottom, last matching section wins
> - if multiple .editorconfig are found (up until one with the root key or
>   in /) closest to the file wins.
>> 
>> What I am trying to get at is if it is possible to make something
>> along this line to work:
>> 
>>     [*]
>> 	charset = utf-8
>> 	insert_final_newline = true
>> 	indent_style = tab
>> 	tab_width = 8
>>     [*.py]
>> 	indent_style = space
>> 	indet_size = 4
>> 
>> I am assuming, without knowing, that the conflict resolution rule
>> may be "for the same setting, the last match wins" so by default we
>> always use "indent_style = tab", but if we are talking about a Python
>> script, it is overruled with "indent_style = space".
>
> So it looks like it's possible, if we also add judiciously .editorconfig
> in subdirectory where we have other files which don't want the same
> settings, probably:

That is much less than ideal---I was hoping that we can do this
with just one file.  My reading of that spec is that in the same
file it would be the last one wins, so something line what I gave
you above should work more-or-less as-is?

Also I am not sure if there is any reason why ...

> - po/
> - t/
> - contrib/
> - .github/
> - ...
>
> Not sure if that's easier than adding stuff to the to the root config
> though.

... t/*.sh should use rules different from those that apply to
check-builtins.sh at the root level, or contrib/mw-to-git/*.perl
should use Perl rules different from those that apply to
perl/Git.pm.  So I think "we need per-directory customization" is a
red herring.

The real potential downside of the approach to use a single default
fallback set of rules with "match everything" is that types that we
did not tweak the editor rules for are suddenly and uniformly
subjected to a rule that may not match the contents.  We currently
do not do anything to .yml or .md so we do not force them to be in
any consistent layout---even if all contributors use editorconfig
aware editor to edit them, they will produce inconsistent result.
If we enforce "everybody indent with tab unless explicitly set
differently like we do for .py", these contributors consistently use
tab indent on .yml or .md, which may not be a suitable convention
for the material.  My quick look says that .github/**/*.yml wants
two-space indentation, and .md are fine with any indentation so
enforcing tab indent consistently may be better than not enforcing
any indent at all.

So, my gut feeling is that forcing "everybody uses tab indent by
default, and file types with specific needs should opt out just like
we do for Python" may initially give us a bit of friction (e.g., We
may find .github/**/*.yml would want different rules, so we would
add "[*.yml]" section just like we have "[*.py]" section), but would
make the rule coverage more complete and more clear.  We would give
a .yml file some rule to follow, which may initially be wrong but we
can fix with explicit rule.

So I dunno.  If the Makefile snippet were the last type of files we
would ever add to .editorconfig, I think the patch under discussion
is a good progress, but if we share the vision of "more complete and
clear rule coverage", it is going in the opposite direction.

Let me take your patch as-is, but leave it #leftoverbits to at least
see the feasibility of switching to "everything falls under the
default set of rules, and specific needs are dealt with exceptions"
model.

Thanks.