on_selection_modified should be called only once and with the view where the selection was modified

[evandrocoan]

Sub-issue from: Multiple event hooks don't work with clones #289

Actual behavior

If I have 10 clones into a view, I get on_selection_modified called 10 times, and each time it always have the primary view as the view parameter.

Expected behavior

If I have 10 clones into a view, the on_selection_modified event should be called only 1 time, with the view on which the selection was modified (not the primary view).

Environment

• Operating system and version:
  • Windows 10 build 15063 x64
  • Resolution 1920x1080
  • dpi_scale 1.0
  • Sublime Text:
  • Build 3207
  • 64 bit

Related threads

1. on_selection_modified gets called twice when left clicking on_selection_modified gets called twice when left clicking #1254
2. Sublime Text cannot call the plugins forwards as on_selection_modified(1) before the plugin goes through the forward plugin_loaded(0) EventHandler hooks (e.g. on_selection_modified) called before plugin_loaded #1508

[deathaxe]

Each cloned view receives the on_selection_modified() with the correct view object being passed, if the selection was modified in one of them. So it is called 10 times if 10 cloned views into one file exist.

It's up to a plugin to handle or ignore the event for all or the active view only.

class MyListener(sublime_plugin.EventListener):

    def on_selection_modified(self, view):
        if not view.window():
            return
        if view == view.window().active_view():
            print(f"on_selection_modified called for active View {view.id()} : {view.file_name()}.")
        else:
            print(f"on_selection_modified called for inactive View {view.id()} : {view.file_name()}.")

[rwols]

I doubt this is an excellent solution to the "cloned view" problem. This puts the responsibility in the hands of plugin developers. It's a "gotcha" that's easily overlooked. On the other hand, it's certainly a solution that we can work with.

[wbond]

Let’s reopen so I can take another look

[deathaxe]

ST can't know whether a plugin wants to be informed about the active view or all views, so this is propably the most flexible solution.

[deathaxe]

With regards to #289 it would mean to propably implement a special behavior for on_selection_modified so only that is called for the active view only?

How about adding a ViewEventListener.applies_to_active_view_only()?

[rwols]

ST can't know whether a plugin wants to be informed about the active view or all views, so this is propably the most flexible solution.

But each view maintains its own selection whether cloned or not. So calling on_selection_modified for a (cloned) view for which the selection was not modified is a bit of a lie IMO ;)

[deathaxe]

ST 4070 still fires the event for all clones.

[wbond]

This branch hasn't been merged yet, I'll update the milestone

[wbond]

This should be fixed in 4072

[deathaxe]

IMHO, this issue is only partly fixed.

It works, if the caret is moved in one of the views without modification to the content.

But if the content changes, the on_selection_modified event is still fired for both the primary and the cloned view.

It might be logical if the caret of the inactive was moved by the modification, but that's not the case.

Please see how the caret of the primary (left) view is moved to the beginning of the file and how the on_selection_modified is still fired for that view (19), if new lines (or characters) are added to the buffer in the cloned (right) view (22) at a later position of the file.

[wbond]

It is probably that we aren’t checking all of the selections in the inactive view to see if at least one is after the modification.