Rename settings and the way settings are loaded - #418
Conversation
* Fixes spadgos#313 * Fixes spadgos#334 * Fixes spadgos#338 * Fixes spadgos#408 * Fixes spadgos#400 * Fixes spadgos#360 * Fixes spadgos#397
e526a87 to
e7a379c
Compare
|
Question: why not just make this use "User/DocBlockr.sublime-settings" instead? I'm using to using separate settings files for each plugin, and I don't see why we would need to use the default Preferences files here. |
|
@ErichDonGubler There are many more problems with using named settings files than using the built-in preferences. I think it's a bad practice to use named settings files. I wrote up an explanation of this on SO: https://stackoverflow.com/a/43698128 . There are also a few other issues I didn't go into e.g. settings from named settings files are not automatically available to keymaps, in fact how would you make settings from a named settings file available to be used in a keymaps file? See the example of keymaps usage in the SO answer. So, preferences can be used in keymaps file like so: How would you do that from settings in a named settings file? There are lots of little issues like this that are solved out-of-the-box by using built-in preferences. |
For the most part this is backwards compatible, though there are some edge-case bc breakages.
Base File.sublime-settingstoDocBlockr.sublime-settings#313What does it change?
jsdocs_*todocblockr.*.User/Preferences.sublime-settingsinstead ofUser/Base File.sublime-settings.The trickiest part is making sure the refactor is backwards compatible. See here for relevant settings migration code.
Is this something that will be accepted to merge?
I'm happy to address any issues to get this change merged.