| Message ID | 20240322221813.13019-1-mg@max.gautier.name (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | b45602e392398f29be0af1ac7e202b996f99c747 |
| Headers | show |
| Series | editorconfig: add Makefiles to "text files" | expand |
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.
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 <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.
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 <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.
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
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(-)