warning:
* may be buggy
This commit adds support for sideways splits into Irssi. To that regard,
there are a number of new commands available
the "R" commands:
/window new rsplit - make a new sideways split
/window rshow - show an existing window to the right
/window rgrow/rshrink/rsize/rbalance
- manipulate the size of your sideways split windows
the "D" commands:
/window dup/ddown/dleft/dright
- navigate the windows directionally, as an alternative to
/window up/down that you can bind to some key
/window move dleft/dright - the same for moving
Enjoy!
Initialize tagtarget on declaration
move code around for better flow, extra checks for uninitialized values
remove unnecessary item->type checks
don't strdup sign
add braces around if statements, use strcmp0 with single characters and remove g_str_has_prefix
refactoring
changed g_ascii_strcasecmp to g_strcmp0
Add networktag/ shorthand
fixed memory leaks
changed from #@= to ::channels, ::queries and ::dccqueries
check for empty string and continue; if found
fixed bug with empty string check
Clean up code
it is possible to use Irssi::UI::Window::get_history_entries to save the
history entries, load_history_entries to load entries into the command
history and delete_history_entries to remove history entries (for example
to remove history selectively)
this allows access to the global history even when a using /window history
named or /set window_history on, and you want to recall something from one
of the other windows' histories.
usage (default): ctrl+up/down
Originally found by oss-fuzz (issue 525) in get_ansi_color using ubsan.
After a lot of analysis I'm 99% sure this isn't security relevant so
it's fine to handle this publicly.
The fix is mainly adding a function that does it right and use it
everywhere. This is harder than it seems because the strtol() family of
functions doesn't have the friendliest of interfaces.
Aside from get_ansi_color(), there were other pieces of code that used
the same (out*10+(*in-'0')) pattern, like the parse_size() and
parse_time_interval() functions, which are mostly used for settings.
Those are interesting cases, since they multiply the parsed number
(resulting in more overflows) and they write to a signed integer
parameter (which can accidentally make the uints negative without UB)
Thanks to Pascal Cuoq for enlightening me about the undefined behavior
of parse_size (and, in particular, the implementation-defined behavior
of one of the WIP versions of this commit, where something like signed
integer overflow happened, but it was legal). Also for writing
tis-interpreter, which is better than ubsan to verify these things.
