Add the missing arguments to tparm. X/Open Curses specifies
tparm takes a fixed number of 10 arguments, while ncurses
has implemented it as a varargs function. tiparm is a standardized
version of varargs tparm, support in both NetBSD libcurses and
ncurses, but not by older versions of Solaris.
This is an alternate fix to the one proposed in irssi/irssi/#1305
that should keep compatibility with older versions of Solaris by
avoiding tiparm.
If term.h is present, use that instead of defining prototypes for the
terminfo functions in terminfo-core.c. This causes problems on certain
platforms (e.g. Apple aarch64) due to the functions being prototyped as
non-variadic but called as variadic. If term.h isn't found, it falls
back to the old behaviour.
Fixes#1238.
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
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.
