Open Thom1729 opened 3 years ago
I've run into a bit of trouble with GlobalSettingsListener
. It turns out that EventListener
s are never garbage-collected. (I'm pretty sure this is a bug.)
I have solved the problem with a moderately ugly hack. GlobalSettingsListener
implements an on_new
handler that does nothing. Then, in _on_settings_change
, it checks whether that callback is registered. If not, it calls its own __del__
.
After spending several hours debugging this, I'm confident that this was the problem and that the solution works — though I wouldn't call it pretty.
(There's no such problem with ViewEventListener
s.)
@FichteFoll Any thoughts on the above hack?
Regarding the on_new
hack: I think it's reasonable, although I surely wish it wasn't necessary. Yet, I cannot think of a better idea, so LGTM in general.
I wrote up some docs for the projection function. I'm not completely satisfied with it, but it might be good enough.
For #164.
Notes:
OnChangedOptions
is a named tuple so that we can easily support more arguments toon_setting_changed
.async
argument toon_setting_changed
. Alternatively/additionally, we could have a separateon_setting_changed_async
decorator.SETTINGS_NAME = 'Foo'
, we could just havesettings = sublime.load_settings('Foo.sublime-settings')
. I think the former might be slightly less prone to user error.on_setting_changed
decorator outside aBaseSettingsListener
. Haven't looked into implementation yet.ViewSettingsListener
orGlobalSettingsListener
from their plugin, Sublime will dutifully use them. This probably doesn't really matter, but we could special-case this if we want.str(id(self))
? I suspect not.WindowSettingsListener
? I also suspect not.selector
only supports strings and functions, but we could just use_util.collections.get_selector
.