Sublime Forum

New Plugin: Preset Command

#1

The first public release of Preset Command is now available.

Preset Command is a plugin to manage collections of settings presets from the command palette. Compatible with Sublime Text 3 for the moment. Please follow the readme to be able to use Preset Command as it takes little time to customise and no time to use.

As functional as it is already, there are a few planned features which will take shape over the next few days and weeks:

  • Ability to set flags to change Preset Command’s behaviour (e.g. toggle booleans, remove a setting, and arrays for a single setting)

  • Ability to run commands in addition to saving settings (e.g. toggle minimap, sidebar, fullscreen, wordwrap, etc)

Interesting suggestions which require further investigation:

  • Use ST input panels to construct and save a preset without the user opening the file

This plugin is technically pre-release so please create a GitHub Issue if anything breaks.

0 Likes
#2

Looks like a nice addition to have. Unfortunately it ( still ) can not be installed via Package Control. Will have to check it out in the next few days to come.

0 Likes
#3

You can install almost any GitHub or BitBucket hosted plugin via package control, even if it hasn’t been added to the repository.

  1. Search for “Add Repository” in the command palette.
  2. In the input panel, enter github.com/skt84/PresetCommand
  3. Search for “Install Package” in the command palette.
  4. Look for PresetCommand.

Honestly, I think this is one of the most underutilized features in Package Control.

0 Likes
#4

It’s a great trick, this. (Although, unfortunately, there are issues with this method for plugins that try to access their own files in ST3.) But like most of the ST ecosystem, it’s not well documented. I think this is the most common help I’ve provided in these forums. It would be great if there was somewhere to link to. Maybe a documentation initiative with a low bar of entry. Or is there something along these lines that I’m not aware of? Maybe something like @tito’s bugtracker: an empty project with a Git Wiki.

/sorry for the OT mini-rant :smile:

0 Likes
#5

documented here: wbond.net/sublime_packages/package_control/usage

0 Likes
#6

[quote=“quodlibet”]

It’s a great trick, this. (Although, unfortunately, there are issues with this method for plugins that try to access their own files in ST3.) But like most of the ST ecosystem, it’s not well documented. I think this is the most common help I’ve provided in these forums. It would be great if there was somewhere to link to. Maybe a documentation initiative with a low bar of entry. Or is there something along these lines that I’m not aware of? Maybe something like @tito’s bugtracker: an empty project with a Git Wiki.

/sorry for the OT mini-rant :smile:[/quote]

You should make an issue request on those projects for a completely ST3 compatible branch. These plugins should be using “sublime.load_resource()” to retrieve contents. If they want the same branch for both ST2 and ST3, they would just need a simple module like this.


def get_resource(package_name, resource, encoding="utf-8"):
    packages_path = sublime.packages_path()
    content = None
    if int(sublime.version()) > 3013:
        try:
            content = sublime.load_resource("Packages/" + package_name + "/" + resource)
        except IOError:
            pass
    else:
        path = os.path.join(packages_path, package_name, resource)
        if os.path.exists(path):            
            with codecs.open(path, "r", encoding=encoding) as file_obj:
                content = file_obj.read()

    return content

Anyways, getting away from the new plugin announcement. Though, perhaps the plugin will need to do something similar. Just took a look at the plugin and noticed the use of sublime.load_settings(). This returns a Settings object, not a string, so the plugin will fail when it runs. It would be great of jps could make the settings object iterable so this plugin could just look at the keys of interest rather than checking all of the keys in the default settings file.

0 Likes
#7

This isn’t the case anymore. I was originally using load_resource() but it’s not supported in ST2 so I went to try out load_settings() which I dropped until I have something a little more feature complete and stable. So for now I’ve gone back to load_resource() and will be ST3-only for the foreseeable future. The uniterable settings object was a little odd for sure, I didn’t exactly need to use it when loading the items for the quick panel but I’ve since made changes to improve the object handling. Updates will come quickly so I’m not going to post every time I potentially break something.

0 Likes
#8

If you want it to be both ST2 and ST3 compatible, you can try something like that code snippet I posted. ST2 settings are much simpler as all the settings will exist in the Packages folder. In ST3, these can be in the executable directory, installed packages directory, or packages directory. Though you will have to manually remove comment strings in ST2.

That’s fine, I just thought it was in a stable state since you made an announcement about it, but it’s not a huge issue that it wasn’t. If you think you will be committing broken code, consider creating a dev branch to work on. This is especially important if you want people to install via package control. Package control will grab the latest version of your master branch by default. You probably don’t want broken versions being used by end users.

0 Likes