With 3.2.3, after selecting open edit on startup and using ^O to select a file, I got a silent close of the editor window. Opening from the file menu worked. After the change of adding '0', ^O worked also.

However, without a test suite, I am a little nervous about the change, as the original code might be intentional. From the module doc string:

"The order by which events are called is defined by these rules:
1. A more-specific event will be called before a less-specific event.
2. A recently-binded event will be called before a previously-binded event, unless this conflicts with the first rule."

Is popping from the end the implementation of rule 2?
Is it possible that one event pair is being appended in the wrong order?
I need to read more of the comments and code to understand this subsystem.


Code note 1: doafterhandler = self.doafterhandler (initially [] by default), so changes to the list must be mutations to affect the self attribute.

while doafterhandler:
    doafterhandler.pop(0)()
# is O(n*2)

doafterhandler.reverse()
while doafterhandler:
  doafterhandler.pop()()
# is O(n)

for f in doafterhandler:
    f()
doafterhandler[:] = []
# doafterhandler.clear() works in 3.3
# is also O(n) and replaces repeated .pop with one clear

If calling first to last is proper, I prefer this last unless the callback functions somehow require that they be removed from doafterhandler before being called.


Code note 2: unless the default args for handler

    def __create_handler(self, lists, mc_type, mc_state):
        def handler(event, lists = lists,
                    mc_type = mc_type, mc_state = mc_state,
                    ishandlerrunning = self.ishandlerrunning,
                    doafterhandler = self.doafterhandler):

are ever replaced with other arguments in handler(event) calls, their presence in the signature would appear to be holdovers from before closures. If so, the above could be simplified to
        def handler(event)
and 'self.' added in the body where needed.

I also wonder whether the double underscore and consequent name mangling for __create_handler is needed. My understanding is that this is only needed, perhaps, for multiple inheritance mixin classes, and I do not see that class _ComplexBinder qualifies.