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

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

[Max Gautier]

The Makefile and makefile fragments use the same indent style than the
rest of the code (with some inconsistencies).

Add them to the relevant .editorconfig section to make life easier for
editors and reviewers.

Signed-off-by: Max Gautier <mg@max.gautier.name>
---
 .editorconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.editorconfig b/.editorconfig
index f9d819623d..15d6cbeab1 100644
--- a/.editorconfig
+++ b/.editorconfig
@@ -4,7 +4,7 @@ insert_final_newline = true
 
 # The settings for C (*.c and *.h) files are mirrored in .clang-format.  Keep
 # them in sync.
-[*.{c,h,sh,perl,pl,pm,txt}]
+[{*.{c,h,sh,perl,pl,pm,txt},config.mak.*,Makefile}]
 indent_style = tab
 tab_width = 8
 
-- 
2.44.0

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

[Junio C Hamano]

Max Gautier <mg@max.gautier.name> writes:

> The Makefile and makefile fragments use the same indent style than the
> rest of the code (with some inconsistencies).
>
> Add them to the relevant .editorconfig section to make life easier for
> editors and reviewers.
>
> Signed-off-by: Max Gautier <mg@max.gautier.name>
> ---
>  .editorconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/.editorconfig b/.editorconfig
> index f9d819623d..15d6cbeab1 100644
> --- a/.editorconfig
> +++ b/.editorconfig
> @@ -4,7 +4,7 @@ insert_final_newline = true
>  
>  # The settings for C (*.c and *.h) files are mirrored in .clang-format.  Keep
>  # them in sync.
> -[*.{c,h,sh,perl,pl,pm,txt}]
> +[{*.{c,h,sh,perl,pl,pm,txt},config.mak.*,Makefile}]
>  indent_style = tab
>  tab_width = 8

A question out of curiosity (because the answer does not affect any
conclusion): Does editorconfig attempt to cover any non-text files?

Two more questions that do affect the conclusions are:

 * 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?

 * Does .editorconfig file allow possibly conflicting setting, with
   a reliable conflict resolution rules?

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".

If that is possible, we do not have to keep adding "ah, files that
match this pattern are also text", i.e., everything is text and
indented by tab, unless specified otherwise.

Thanks.

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

[Max Gautier]

On Fri, Mar 22, 2024 at 03:40:59PM -0700, Junio C Hamano wrote:
> A question out of curiosity (because the answer does not affect any
> conclusion): Does editorconfig attempt to cover any non-text files?

Apparently they it does not differentiate binary files:
https://github.com/editorconfig/editorconfig-core-js/issues/42
https://github.com/editorconfig/editorconfig/issues/285#issuecomment-267400370

> Two more questions that do affect the conclusions are:
> 
>  * 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 | \
    grep -vE '.*\.(c|h|sh|perl|pl|pm|txt)' | grep -v t/ \
    | rev | cut -d . -f -1 | rev | sort | uniq -c | grep -vE '\<1\>'
-> gives for a first approximation (much more if not filtering unique
occurrences)
      2 bash
      2 el
      8 gitattributes
     15 gitignore
      4 go
      2 in
      7 js -> git-gui + git-web
      8 md
      2 png
     41 po
      2 pot
     14 sample
     41 tcl -> git-gui
      5 xsl
      5 yml -> ci stuff
Not sure which one among those don't want the same tab-indent settings
though.


> 
>  * 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:
- po/
- t/
- contrib/
- .github/
- ...

Not sure if that's easier than adding stuff to the to the root config
though.

-- 
Max Gautier

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

[Junio C Hamano]

Max Gautier <mg@max.gautier.name> 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.

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

[Max Gautier]

On Sat, Mar 23, 2024 at 10:36:01AM -0700, Junio C Hamano wrote:
> >>  * 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?
> 

I read it the same way, I didn't intend to imply using one top level
only was not possible ; sorry for the lack of clarity.

> 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.

Oh, I was more thinking about the other stuff under t/ , not she scripts
themselves, there is some .test, .diff, lots of files without extensions
(some css apparently, among other stuff) , and without looking in
details, my best guess is that most of this is test samples (=> I mean
things used by the tests to compare / test processing result).
I don't know if that's supposed to be edited manually though.

But yeah, "per-directory customization" isn't good, it multiplies the
place to look when the config is not correct. I was mentioning by fear
that using only one file would be hard to manage is there is too much
patterns. 

-- 
Max Gautier

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

[Junio C Hamano]

Max Gautier <mg@max.gautier.name> writes:

> But yeah, "per-directory customization" isn't good, it multiplies the
> place to look when the config is not correct. I was mentioning by fear
> that using only one file would be hard to manage is there is too much
> patterns. 

Understood.

My primary point is that we are not using too many patterns
currently, and hence many files are *not* covered by .editorconfig
rules.  Some files may not even be meant to be edited by an editor,
but many others are allowed to be edited without enforcing any style
with .editorconfig and how to format them is up to the developers.
Applying a default rule to these files to enforce consistency may be
better than uncontrolled random mess each developer may leave
without any rules, and at the same time, doing so would mean we do
not have keep adding to the "C uses this rule, Shell uses this rule,
oh, now we also want Makefile to use this use" enumeration.

There may be fallouts (i.e., "For files of type X that currently are
not governed by .editorconfig, the indent-with-tab rule is not
suitable, but suddenly these files are subject to the default rule")
but adjusting the rules with exception would be more explicit and
clarify the rules.