@Trey-Hunner ,
BTW, in response to this comment:
if EditorConfig was built-in to Notepad++, I wouldn’t need to do this. I’m hoping that Notepad++ will add built-in support for EditorConfig, …
Some hints about the development philosophy of Notepad++:
if it’s already implemented by a plugin, there is very little likelihood it will be implemented natively
if it’s already configurable by the settings, then there’s little chance the default setting will be changed, because it just takes a change to the settings
if you don’t like the default settings bundled with Notepad++, you can make a new bundle with the settings configured the way you like it; this can either be done by
starting with the zipfile distribution, and you edit the files in the zip, and you distribute the modified zip
having the users install from normal installer, and you just distribute the updated settings files
furthermore, as I said a while ago, the default settings on this one did change, so the default settings now match what you want.
… built-in support for EditorConfig, just as BBEdit, Komodo, Visual Studio, PyCharm, and other editors have done.
FYI:
bbedit: development paid for by buying the software
komodo: has the financial power of ActiveState to pay for its development
visual studio: has the financial power of Microsoft to pay for its development; not all versions are free
PyCharm: that one looks like it might be truly free, developed by volunteers rather than paid employees
So you’ve listed one common example of a comparable software that’s free (freely developed, freely maintained, freely downloaded), that has implemented the EditorConfig natively. My response to that: “That happens”. Different OpenSource software in the same space (like different text editors) gets developed because different teams have different goals for the important feature sets, and whether those features should be implemented natively or by plugins.