A change in GLib 2.63 broke some assumptions in Irssi that the null-byte
NUL / U+0000 is a valid Unicode character. This would occur when the
user types Ctrl+Space. As a result, the input loop never manages to
process the NUL-byte (and any other user input that follows, ever).
This patch adds a manual check that properly advances the input loop if
GLib returns -2 (incomplete character) despite the length being positive
and a NUL is in first position.
Fixes#1180https://gitlab.gnome.org/GNOME/glib/-/merge_requests/967https://gitlab.gnome.org/GNOME/glib/-/issues/2093
- the expando values need to be stored now that the lines are
reformattable, otherwise the old values are lost (and they depend on
context only available at the time the line is initially printed)
- the cache is collected from the special-vars evaluation code
- the cache is controlled by the textbuffer-formats code, and stored in
the text_buffer_format_rec
- completely removed the old textbuffer representation (
https://github.com/shabble/irssi-docs/wiki/Notes-256-Colour#textbuffer-encoding
)
- textbuffer-formats is an extra module, so if we unhook the signals it
should go back to the "old way" of storing pre-rendered tex
- design uses cache, original formats and list of arguments
Track the address family of the last failed connection attempt
(either immediately or during TLS handshake), then disprefer
that address family during reconnection.
Most of these have been deprecated since forever (2.2), but they didn't
raise warnings. Now they do, and the warnings are not the most verbose
warnings you could ask for, but, they point in the right direction.
This doesn't handle the GTimeVal deprecation warnings. Those seem
trickier since they cover API, will look into those right after this.
If irssi's preferred nick is in use irssi will issue a whois command and report some information
on the current user of the nick. As the "is owned by" wording can be confusing to users of networks
with nickname registration, propose rephrasing this to "is in use by".
This was causing us to use the TLS settings from one server on another
which is not always appropriate. Instead, we now treat it like other
connection information and do not copy it. We get the TLS settings later
as appropriate when connecting.
Note there is still probably more that could be cleaned up here. For
example, the unix socket might be better treated as connection info too.
Fixes#1027.
This patch allows irc_op_public messages to properly trigger
hilights when the message mentions the current nick or one of our
hilights. This is done by copying the required code from
sig_message_public. This is important because Freenode has begun
using this message type for messages that can only be seen by ops
due to the +z channel mode, and ops will want to be notified of
watchwords even in that type of message.
To test, make two connections to Freenode, join a new channel. The
first client to join that channel will be an op. To establish a
baseline, use the non-opped client to attempt to "ping" the opped
client by addressing it by name and using terms in /hilight. Then,
set channel mode to +mz and use the non-opped client to send the
messages again. Without this patch, no message will "ping" the opped
client with +mz set. With this patch, "pings" should operate
normally, causing a bell, hilighting the window number, and so on.
What I don't know is whether there is any other code from
sig_message_public that should be copied over too. In particular,
the lines related to "ignore_check_plus", "emphasis", and
"printnick", I don't know if they are needed here. I also don't know
if there are any other message types that these changes should be
applied to.
