GNU nano - Bugs: bug #61947, [Wish] add support for...
You are not allowed to post comments on this tracker with your current authentication level.
bug #61947: [Wish] add support for editor-config files
Submitter: | Mike Frysinger <vapier> | ||
Submitted: | Thu 27 Jan 2022 09:32:48 PM UTC | ||
Votes: | 1 | ||
Severity: | 1 - Wish | Status: | None |
Assigned to: | None | Open/Closed: | Open |
Sat 29 Jan 2022 06:27:16 PM UTC, comment #4: |
Mike Frysinger <vapier>![]() |
Sat 29 Jan 2022 02:35:18 PM UTC, comment #3: 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.) |
Benno Schulenberg <bens>![]() |
Fri 28 Jan 2022 07:15:08 PM UTC, comment #2: the tab/indent options are actually the ones i had my eye on. i work on many diff codebases that have very diff tab/indent styles, and it's a huge pita to constantly remember to specify the right -T option when flipping between them. and yes, it means if i have a multibuffer session viewing diff files with diff styles, then it still doesn't work well, and i have to have different nano instances running.
the point of supporting this config file format isn't so much for nano users to do things locally in their own personal stuff, but to leverage the configs being checked in to projects that you contribute to. if it were scoped narrowly like that ("this is just a way for nano users to write ~/.nanorc"), i'd agree that the format isn't worth the effort. but when it's scoped to "projects are using this to export settings in an editor-independent way, and all contributors to the projects get the right setup for free", i think it takes on a different light. |
Mike Frysinger <vapier>![]() |
Fri 28 Jan 2022 04:40:54 PM UTC, comment #1: (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.
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. |
Benno Schulenberg <bens>![]() |
Thu 27 Jan 2022 09:32:48 PM UTC, original submission:
came across this today:
an editor-independent ini config file for declaring things like indent style & size on a per-file basis
thoughts on supporting it in nano ?
if you're looking for an iniparser library, i've used this one in C before and it's nice -- easy to use, and small.
|
Mike Frysinger <vapier>![]() |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There is 1 vote so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
kind of seems like editing files is the target area of nano. it also doesn't seem unusual considering how many editors already support it, or have a framework for supporting it, or support embedding their own config settings in a file. nano stands out as an inflexible editor here with literally no alternative.
adding another option to control the setting doesn't seem like a big deal.