(e.g. “/join @conference.prosody.im”)
- If the current tab is a MUC the @ prefix is mandatory as there is no
way to tell if the user meant a room name or a domain.
- If it is not a MUC, then the @ prefix is not mandatory (but works
anyway)
When an external (or internal) event may cause the order of the
cache to be modified, or new elements to be added, schedule it
for a rebuild. Otherwise, don’t, and only rebuild it when
refreshing (that should improve refresh speed a lot).
Also, if the position in the roster is further than the total size
of the roster, go back to the top instead of displaying an empty
window with “+++”.
- Do not crash because of low disk space
- Notify the user whenever it happens
- A few functions now return a boolean instead of nothing
- Config.silent_set is Config.set_and_save without toggle and returning
strings. It is used whenever we don’t need set_and_save
- Config.set_and_save now returns a tuple (that can be passed directly
to core.information())
TODO: display the precise error to the user (instead of “unable to…”)
- The input is split in two parts: on the left is what the user enters,
on the right is the first match (the right part has a different
color)
- Start and cancel a search with ^R
- Validate a search with enter, then press another time enter to send
- CommandInput and MessageInput now inherit from the HistoryInput class
and share some methods
- Refactor the message handlers to be more readable
- Add a group_corrections tab-specific option (#2229)
- Fix issues with /correct in private tabs and conversation tabs
- Added as always new theming variables:
CHAR_ROSTER_MOOD, CHAR_ROSTER_ACTIVITY (a SNOWMAN!)
COLOR_ROSTER_MOOD, COLOR_ROSTER_ACTIVITY
- Added two new notification types in Theme.INFO_COLORS (mood/activity)
- Added new configuration options:
display_mood/activity/tune_notifications (those can be set for a
specific JID)
enable_user_tune/nick/activity/mood
- Added /activity and /mood commands, with completions
- Moved the old /activity to /last_activity
- Details are show in the ContactInfoWin if there is room, or with "i"
on a contact in the roster.
- add a use_pep_nick boolean option
- use it as a nickname for roster contacts, but it does not
supercede the user-defined handle
- send a <nick/> at the beginning of a normal chat
- not implemented in MUC (wontfix)
Also:
- Add get_conversation_messages() to PluginAPI
- Make plugins_autoload colon-separated instead of space-separated
(for consistency)
- Replace a JID() with a safeJID() in the uptime plugin
- add methods related to timed events to the PluginAPI
- remove parse_command_args_to_alias because str.format does that, and
better
→ update the alias plugin
- Try to reduce the use of the “core” object in the plugins
- New “api” member for each BasePlugin which is a wrapper around
the unique PluginAPI object. (instead of having the methods
directly in BasePlugin and then calling the PluginManager)
- Documented methods with rst (for sphinx)
- Prevent correction of delayed messages
- Prevent correction of messages by someone else in a MUC (and in a
private tab)
- Messages with unauthorized corrections (above) or wrong message id
will be displayed as normal messages
TODO: restrict the corrections to the same fullJID (only in direct
"normal" conversations, because we can know in private an muc tabs, via
the User object)
This makes it easy to review all the highlights after the separator was
placed, using M-h, M-n, M-n, M-n…
We just add a counter of highlights which is incremented each time there’s
an hl, and set to zero when we reset the separator. We use that counter to
set hl_pos when we scroll to the separator.
With a few specific behaviours: When manually opening a conversation with a
bare jid, we open a normal conversation that follows the XEP (locked and
unlocked accordingly). If the user manually opens a conversation with a
fulljid (by selecting a specific resource in the roster, or by specifying a
fulljid to the /message command), we open a special tab that doesn’t follow
the XEP (it is always locked to the same resource, and cannot be unlocked).
When a message is received, unless a special tab has been manually opened by
the other with that specific resource, we always send the messages to a uniq
normal tab, unlocking or locking it according to the XEP.
This means that only one tab can be opened with a given contact, unless the
user specifically chooses to open a special tab for a specific resource.
fixes#2159
