Home Download Buy Blog Forum Support

Storage of package specific settings

Storage of package specific settings

Postby cryzed on Tue Mar 13, 2012 11:49 pm

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:

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

Re: Storage of package specific settings

Postby tito on Wed Mar 14, 2012 12:17 am

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.
Give APIs, let the community build the rest!
https://github.com/titoBouzout
tito
 
Posts: 854
Joined: Thu Sep 29, 2011 2:27 pm
Location: Montevideo, Uruguay

Re: Storage of package specific settings

Postby cryzed on Wed Mar 14, 2012 12:28 am

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.
cryzed
 
Posts: 18
Joined: Sat Jan 14, 2012 5:10 pm

Re: Storage of package specific settings

Postby C0D312 on Wed Mar 14, 2012 12:32 am

cryzed wrote:discussed this with another user in the IRC channel

cryzed wrote:<jskinner>


Made me chuckle. Wouldn't say Jon's "another user" :D

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...)
C0D312
 
Posts: 1063
Joined: Sun Jul 10, 2011 3:23 am

Re: Storage of package specific settings

Postby cryzed on Wed Mar 14, 2012 12:37 am

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.
cryzed
 
Posts: 18
Joined: Sat Jan 14, 2012 5:10 pm

Re: Storage of package specific settings

Postby tito on Wed Mar 14, 2012 12:46 am

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.
Give APIs, let the community build the rest!
https://github.com/titoBouzout
tito
 
Posts: 854
Joined: Thu Sep 29, 2011 2:27 pm
Location: Montevideo, Uruguay

Re: Storage of package specific settings

Postby cryzed on Wed Mar 14, 2012 1:32 am

Yes, that sounds great :)!
cryzed
 
Posts: 18
Joined: Sat Jan 14, 2012 5:10 pm

Re: Storage of package specific settings

Postby facelessuser on Wed Mar 14, 2012 3:42 am

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.
facelessuser
 
Posts: 1571
Joined: Tue Apr 05, 2011 7:38 pm

Re: Storage of package specific settings

Postby cryzed on Wed Mar 14, 2012 11:22 am

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.
cryzed
 
Posts: 18
Joined: Sat Jan 14, 2012 5:10 pm

Re: Storage of package specific settings

Postby FichteFoll on Sat Mar 17, 2012 11:43 am

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

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?
FichteFoll
 
Posts: 388
Joined: Fri Mar 16, 2012 11:49 pm
Location: Germany

Next

Return to Ideas and Feature Requests

Who is online

Users browsing this forum: No registered users and 4 guests