Sublime Forum

Storage of package specific settings

#1

The current way package specific settings are stored is likely to raise problems in the future. I already discussed this with another user in the IRC channel and we didn’t seem to agree; I’ll simply paste the log of the conversation here because I think it does a decent job at explaining the problems I foresee. Parts between enclosed brackets are edited for clarity:

[quote]…]
Hey there, quick question regarding the Sublime Text 2\Packages\User\Base File.sublime-settings file
This configuration file is apparently used by several different packages that I’ve got currently installed, e.g. SublimeLinter and and SublimeCodeIntel
Is this a fault of Sublime Text 2 or how the individual packages handle user-specific settings?
Base File.sublime-settings is the old name, it’s called Preferences.sublime-settings now
it contains all the user specified settings, and some plugins define their own
I’m not sure what you mean by ‘fault’
Well… I do have a Preferences.sublime-settings file
But when I navigate over Preferences->Package Settings->SublimeLinter->Settings - User
Sublime Text opens the Base File.sublime-settings
in the earlier mentioned directory
the plugin hasn’t been updated to account for the name change then
So in case they do get updated: I have mixed key-value pairs for different plugins in a single file?
you can place your settings in Preferences.sublime-settings, and they will almost certainly still be picked up by the plugin
yes
Isn’t that a bit short-sighted? As in what happens if 2 packages have the same key
no, it’s not
you could say the same thing about what if two plugins pick the same config file name
or the same plugin name
That’s why having package-specific user settings file is a good idea
or at least a convention to name them accordingly “Package Name.sublime-settings”
This currently certainly isn’t a good solution
no, that would be painful
That would be well planned
currently there’s one place to put all configuration settings
splitting them up between multiple files would just add complexity for no return
Except that it wouldn’t really. Sublime Text 2\Packages\User<Package Name>.sublime-settings or alternatively Sublime Text 2\Packages\User<Package Name>*.sublime-settings
There’s not much more complexity there and it prevents that fault
Also there’s not really a difference for the end user if you access these files over the menu shortcuts
there’s a large difference, as now the user would have an explosion of menu items
and it doesn’t solve any problems
The amount of menu items stays the same
And it does solve the earlier mentioned problems
Maybe we are talking about different things, let me take a screenshot
*
So one would access Preferences/Package Settings//(Settings – User|Settings – Default)
If you click “Settings – User” Sublime Text 2 opens] Sublime Text 2\Packages\User<Package Name>.sublime-settings or alternatively Sublime Text 2\Packages\User<Package Name>*.sublime-settings
And as mentioned the amount of menu items would stay the same, so I don’t see what you mean
jskinner, ping
…]
As a tradeoff Sublime Text 2 could still prioritize the settings found in Preferences.sublime-settings, so you can keep all your settings in a single file until the scenario I mentioned earlier occurs
…]
*[/quote]

0 Likes

#2

Agree,

Having package-specific user settings files is good because you keep everything organized and cleaned.

If you need to look for a preference you know where to find it. Scanning a big json with settings from everywhere is pretty confusing.

Also, when you uninstall a package you know which file to remove to get ride of all the package specific things in a very easy way.

Having a big json file will raise the same problem that Firefox has with preferences. You uninstall an extension and the preferences of that extension still exists. After some time the preferences database will grow to something not maintainable. This is specially true when testing a new product with growing packages.

0 Likes

#3

Glad that someone else agrees. In my honest opinion the way it is currently handled is akin to making every variable in your source code global and hoping for the best, i.e. that no other part of the source code (package) changes/accesses/overrides it.

0 Likes

#4

Made me chuckle. Wouldn’t say Jon’s “another user” :smiley:

On that note, what IRC channel’s this? Didn’t know Jon was there too. Damn, Jon, you’re EVERYWHERE.


(For the confused: Jon’s the developer…)

0 Likes

#5

Well oops, I didn’t know that he was the developer – but that shouldn’t affect my opinion on the matter in the first place. You can find the channel here.

0 Likes

#6

Ideal will be to have inside every package a folder called “User” and another called “data”

“SublimeText/Packages/coolPackage/User/” to store anything that will overwrite the default package settings or anything the user want to put there.
“SublimeText/Packages/coolPackage/Data/” to allow to the package developer store some bits of info that are not editable/interesting for users, but this folder does not get trashed when updating or downgrading the package.

This way, when you want to edit something about a package you just enter to the package folder. If you uninstall the package, everything gets trashed. And when updating you don’t lose things.

0 Likes

#7

Yes, that sounds great :smile:!

0 Likes

#8

Not sure I would like having the user content in the plugin folder. Right now I like it all in User (granted I like my plugin files separate). This allows me to just back up the User folder. Package Control takes care of downloading all the plugins if I drop my user folder into a new system. It makes it so easy for me to now manage all of my settings across machines.

But I do understand why you would like it though. One thing I also am not fond of is plugins using Preference.sublime-settings to store their settings. It just jumbles things up for me.

0 Likes

#9

What about storing anything that will overwrite the default package settings in “SublimeText/Packages/User//” and for stuff like default settings and other data that the plugin wants to store “SublimeText/Packages//”. 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.

0 Likes

#10

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).
Additionally you can set language specific configurations (e.g. “User/JavaScript.sublime-settings”), but not for packages.

I also support the “SublimeText/Packages/User//” method. A great advantage would be to just ‘not load’ a settings file in “/User/” 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?

0 Likes

#11

Seems like this has been implemented in the release version of Sublime Text 2, thank you.

0 Likes