More specifically, deferred enable is used if you need to access in your enable that would not be present at the point plugins are loaded (ie. if you need state other than settings, events, and providers). This is in practice used mostly for adding things to the UI, but there are other events for the load of individual components of exaile (player_loaded, playlists_loaded, etc.) if such a point would be more appropriate for your plugin. Take a look at xl/main.py for a better idea of how the startup goes and what events are available.
In this particular case, as Mathias says, you don't access anything that would require a deferred handler, so you can just remove that code and enable() directly.
One minor stylistic point - please do not use all caps in the logging messages. E.g. instead of "INHIBIT SUSPEND: Inhibiting", something like "Suspend inhibited" would be more appropriate.
More specifically, deferred enable is used if you need to access in your enable that would not be present at the point plugins are loaded (ie. if you need state other than settings, events, and providers). This is in practice used mostly for adding things to the UI, but there are other events for the load of individual components of exaile (player_loaded, playlists_loaded, etc.) if such a point would be more appropriate for your plugin. Take a look at xl/main.py for a better idea of how the startup goes and what events are available.
In this particular case, as Mathias says, you don't access anything that would require a deferred handler, so you can just remove that code and enable() directly.
One minor stylistic point - please do not use all caps in the logging messages. E.g. instead of "INHIBIT SUSPEND: Inhibiting", something like "Suspend inhibited" would be more appropriate.