cryzed wrote:What about storing anything that will overwrite the default package settings in "SublimeText/Packages/User/<Package>/" and for stuff like default settings and other data that the plugin wants to store "SublimeText/Packages/<Package>/". As mentioned in the log one could still have a "SublimeText/Packages/User/Preferences.sublime-settings" that would overwrite any settings found in either of the two directories -- so keeping all the settings in a single file, i.e. "Preferences.sublime-settings", would still be possible until the problem arises.
What's confusing here is that this is already possible with other configuration files (tested with .sublime-keymap
(which has the same scope; it's global) and .sublime-menu) and works quite well (except that you can't override an already existing menu with the same keys in the .sublime-menu file, but that's obviously by design).
I also support the "SublimeText/Packages/User/<Package>/" method. A great advantage would be to just 'not load' a settings file in "/User/<Package>" if that package is not loaded (->disabled) or not in the "/Packages" dir. So options that are required for only for a package wouldn't even be loaded if the package does not exist. Not to mention that this is really cleaner and easier to locate if you do that with all your plugins.
On a side node, something that would simplify organizing the whole settings stuff:
I thought about a menu or rather an actual view that contains all the applied settings
(and keymappings) but separates those from different files
. So you have kind of 'special view' that in fact operates like a scrollable
multi-row view with headers (not as high as the tab bars). Probably in the order of precedence (Package/Default->Package->User->User/Package; or whereever these files are located as well).
Think of it as a tree view. You have the filenames as parents and when expanded you see the file's contents and edit it just as normally.
This could even make debugging of your settings easier, e.g. you can determine if a setting was overridden or if it was even "included" since it would have to be present in that view somewhere. And if it's getting to messy you can edit the files manually just like it was before.
Furthermore, one could gray out the overridden settings so it would become even more intuitive, but otoh I don't think this is what sublime is built for, so the above should do it already.
What do you think about that?