Duplicate Editor Config Syntax
Closed this issue · 3 comments
There's an https://packagecontrol.io/packages/EditorConfig package which seems activly maintained.
It does not only provide a syntax definition but also useful functions to apply editorconfig settings to ST.
It may be worth contributing an improved syntax definition to that package instead of messing all kinds of ini like syntaxes into this package. I know that means to copy some rules, yes, but that might be a cleaner solution.
So you mean to move the syntax from here to that package and remove it here, or just copy it but keep it here as well?
I wanted to add this INI Syntax package to package control, and it was suggested in wbond/package_control_channel#8020 to replace the INI package and hence add all the file extensions (including .editorconfig) listed there to achieve feature parity. I also think it's useful to have a syntax for .editorconfig files here, because they are just INI files and perhaps people might want to have syntax highlighting for them without having to use the EditorConfig package.
But I'm not sure right now which of the syntaxes is used if both packages are installed. If @sindresorhus wants to use the syntax from here, of course they are free to copy it, and I guess I could provide a version with the - include: INI.sublime-syntax#... statements replaced with the actual contexts.
It just seems a bit odd to have several packages installed with overlapping features.
EditorConfig provides the basic INI.tmPreferences together with a dedicated EditorConfig.sublime-syntax (which is just an alias).
Now this package provides the same - but more modern / superior - implementation for those syntaxes, too.
Someone who just wants EditorConfig would propably install that package only and expect files being highlighted correctly even though an INI package may not be present. It's also logical to add .editorconfig support from the INI point of view, but I wouldn't propably expect INI Syntax to be the package to provide highlighting for editor config in the first place - if I wasn't a Windows user.
I must confess/state: The current situation with INI / REG / EditorConfig packages is exactly the same.
If both packages are installed the editorconfig syntax of INI Syntax would win the battle as it is loaded later and therefore overrides the one from EditorConfig package.
Maybe EditorConfig should just provide the plugin functionality and ask users to install INI Syntax package for proper syntax highlighting, once it is added to package control. Not sure if that would happen though as it degrates EditorConfig package somehow.
Maybe it's not perfect to duplicate functionality, but in my opinion the best option we have is to keep the editorconfig syntaxes in both the EditorConfig and INI Syntax packages, so that exclusive users of only one of these packages still get highlighting for those files. I think it makes sense to provide the highlighting functionality from the perspectives of both of the packages, and as you said it's the current state with the old INI package as well.
If you want, feel free to create a PR to EditorConfig to replace their syntax file with the syntax version used here (i.e. an adjusted standalone version). I'm fine with and hereby give permission if doing so without copying the license file from here, if you wonder about that.
Since the load order favors the "better" syntax from INI Syntax anyway if both packages are installed, I don't see a necessity to create a PR there myself, unless explicitly requested by the EditorConfig package author.