Hopefully this is a quickie. Is it permitted to add additional keys/fields to the sublime-project files? The unofficial documentation says that everything should be under folders, settings, and build_systems. If I implement plugin specific settings or keys, am I allowed to add a top level metadata field, or should I plan on putting everything under settings? I am thinking there might be some things that would be best customized under a project settings (standardized project name field I could read, project settings, etc).
EDIT: Just remembered my other question that I hadn’t been able to resolve. I’ve got some paths in my addon that are less relative than I’d like. For instance, I reference a snippet from my *.py document like so:
As far as I’m aware you’re able to do this if you wish; the project data seems to be just a regular python dictionary, where some keys are treated specially. At least, simple tests show that doing so seems to cause no harm and the data is retained across calls and restarts.
Using your own key requires you to use window.project_data() to get at the project data every time you perform an operation, while if it’s a setting it would automatically be applied to every view of every file, allowing you to just check settings on a view. Depending on what you’re doing that may or may not be easier, though.
I believe that this is the recommended way of doing this, yes. The unofficial docs mention that the insert_snippet command (for example) requires a relative path, and also mentions:
Often, relative paths in arguments to commands are assumed to start at the Data directory.
In that case, your template would need to include the Packages prefix. I suppose if using ${packages} also works (I’ve never tried) and it expands to a full path, you might be able to use a path relative to the current directory.
However I’m not sure that Sublime tracks the physical location of the python file that represents the command so that it could properly interpret a relative path from an arbitrary location. In that case even if it works for you I would suggest trying it when the current file is not a part of your package to see what happens.
Good to know for the top level project data versus settings. There are some options which might apply across all files of the language type, but some only for a file that’s in the current project. It’s actually nice to have both ways of handling it so I can choose what behavior should be project specific, and what behavior should be settings specific. (Also it’s entirely possible that a project setting might override a language setting, in which case I assume I’ll have to do my own override. While I’m sure Sublime handles a settings override in the settings key, it wouldn’t do the same for my own created key.
And the path name I’ll have to experiment with. I am finding it increasingly frustrating to deal with the fact that I made poor choices when naming the top level. My package directory is vhdl_mode, the git project is named VHDL-mode, and then the Package Control is VHDL Mode. I’ve been holding off making changes to the git project because that’ll require a pull request to the Package Control repository and I don’t know how that will affect anyone who has already installed it. But I think probably better now to bite the bullet and get it figured out so that the zipped package file and a cloned version of the repository will work the same way. Using relative paths would let me delay the pain a little longer but probably I should just implement the correct solution.
