I understand that the feature is meant for allowing nano to be used interchangeably with other editors, for letting all those editors automagically treat and present the files of each project in the intended way.  But I don't see that as the target area of nano, and will not work on this.  And even if a complete patch set were supplied, I don't think I would want to apply it.

(Also, it would require an extra option to enable this behavior, because for most users of nano the searching for .editorconfig files would be a waste of time.)

(I learned about editorconfig twelve months ago, when someone mentioned it on nano-devel.  I glanced at it, and thought it too much trouble and not worth the effort.)

Currently, editorconfig knows just seven keys.

• The `charset` key nano cannot support, being fully geared to UTF-8 or plain Latin-1, determining what to do from the locale.  It doesn't handle any other character set.

• Nano doesn't know how to `trim_trailing_whitespace` upon saving a file.  It would be fairly simple to implement, but it would require a new option, because reusing 'trimblanks' for this... I'm not sure that would be a good idea.

• `insert_final_newline` is what nano calls 'nonewlines', with inverted logic.  But it is a global option, and would need to become per-buffer.

• `end-of-line` is the only thing that nano already has on a per-buffer basis, and would be trivial to support.

• `tabwidth` is what nano calls 'tabsize'.  In nano it is a global option, and would need to become per-buffer.

• `indent_size` (`indent_step` would have been a better name) is something that nano does not know.  In nano the indent step is always a tab.

• `indent_style` is what nano implements with 'tabtospaces', where 'unset' equals the style 'tab', and 'set' equals the style 'space'.  Nano's option is global, except when a syntax specifies 'tabgives', then it is per file type.

So, even just supporting the key-value pairs of editorconfig.org would require substantial changes in nano, in how it stores and applies some of its options.  And for supporting the actual .editorconfig files, a large additional piece of code would be required, to search through the directory tree and then parse each found file and see if it contains something for the current buffer, and then parse the options and translate them to nano's ones...  Pfff!

Also, I don't see on editorconfig.org what the editor is to do when `indent_size` is different from `tab_width`.  I would have expected there to be an indent style called 'mixed', where the indent step is half a tab -- the style that nano used to use, and that ncurses still uses -- and the regex files in gnulib use an indent step of a quarter tab.  Of course, these are awkward styles, but they exists in various places, and if the editor can handle styles, then it should handle these too.

So, in short: too much trouble, plus a whole new dependency, for vanishingly little gain.