Max Gautier <mg@xxxxxxxxxxxxxxxx> 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.
