These were still using tabs.ConversationTab that's been replaced by
Dynamic and StaticConversationTab. These class have been introduced
after resource locking was removed in 1:1, because they were needed for
some plugins like OTR.
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
To avoid leaking data when plugin doesn't do stanza encryption. This
will inevitably reduce the number of features available, but users want
to send "secure" messages right.
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
Features:
- Decryption by default once the plugin is loaded if messages contains
the right EME magic
- Encryption of messages only if encryption is enabled for the current
tab
Missing pieces:
- No special treatment done on the order of the treatment for messages
yet
- No special handling of non-Partial(/Full) Stanza Encryption yet (i.e.,
removing stuff other than <body/>)
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
While this command exists in irssi and might be known by some already,
'sb' is not be the most obvious command name for newcomers.
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
Introduce the concept of priority for event handlers, instead of the
position parameter.
The new `priority` parameter replacing `position` should be an integer
between 0 and 100. It defaults to 50.
The previous `position` parameter was only used to insert at a certain
position in the list of handlers (for this particular event). No
reference of it was kept, which means that it was not possible to ensure
an event was called in the position is was supposed to be.
I am now using per-event dicts, containing priority buckets (lists) of
handlers. I am using OrderedDicts to make it easier to loop through all
of the handlers, as insertion happens less often than reading.
I was also suggested using bisect with a simple list of tuples
(priority, handler) per event, but bisect tries to compare bound
methods, which is obviously not possible. Maybe it would be interesting
to find a way use this method instead of OrderedDict as that might be
less resource consuming.
This said, I don't think this part of poezio is a bottleneck at all, so
maybe this is just fine as is.
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
