Uw opmerkingen
If I am reading the explanation correctly, the two lines of code are placed in the (python?) code of the "plugin".
The standard thing that the plugin is going to be doing is reading in the succession of possible settings files it normally listens for.
If a user goes in and modifies the plugin and adds a reference to the project settings using the chained method calls sublime.active_window().active_view().settings(), they are able to then retrieve settings from a project file when available, falling back to the plugin settings as appropriate.
a better piece of demo code might look more like:
// load up the plugin settings
plugin_settings = sublime.load_settings('Plugin.sublime-settings')
// project plugin settings? sweet! no project plugin settings? ok, well promote plugin_settings up then
project_plugin_settings = sublime.active_window().active_view().settings().get('Plugin', plugin_settings)
// get a plugin settings and fallback on plugin_settings if there's no value in project
// or if there are no project settings at all, it'll check itself twice
foo = project_plugin_settings.get('foo', plugin_settings.get('foo')
if anything is wrong, sorry, I don't normally write python, I'm just looking at the code and cargo culting
Customer support service by UserEcho
the code here:
https://github.com/alexnj/SublimeOnSaveBuild/blob/master/SublimeOnSaveBuild.py
seems to show that the sublime.active_window().active_view() object is passed as a second parameter at least in the on_post_save event
this plugin is already wired up to get settings from the project file ...