sed -i 's/hv_store/(void) &/'
This only results in a warning in older gcc versions, but that includes
the one used in the Travis CI environment by default
Fixes issue #187. It's a bit annoying this can't do anything other than
exit, however as there's no schema for the config it's only possible to
validate on use. This level of config can't be accessed from Perl so a
script can't cause Irssi to die (via this method at least).
Before this, doing "TERM=vt100 irssi" showed all text as bold and
blinking because of a failed check of window->term->TI_colors that
was doing (value & 8) and not expecting a value of 0.
The changed lines themselves look a bit weird, but they make more sense
in the context of the original commit, 96a292d4.
Original patch by hondza <sedaj2@gmail.com>, from FS#833. I applied
several needed style changes, and rebased to current HEAD.
This implements the IRCv3.2 self-message extension partially (we can't
announce its support through CAP yet). This is also the format used by
the 'privmsg' znc module, and is already implemented by several other
clients.
At some point in the past few years, Flyspray changed its URL scheme from id=nnn to task_id=nnn, which broke some old comments in the source. Update those comments to URLs that still work.
Try to split long lines on spaces to avoid words being splitted. This
can be turned off with the option `split_line_on_space'. The code
assumes that the terminal encoding has ASCII spaces.
The userhost Irssi uses for line splitting can in some cases be wrong,
for instance when a proxy is used or when a server cloaks the hostname
without telling the client. Now Irssi always assumes the userhost is of
maximum length. 10 for username (common value) and 63 for hostname (in
RFC 2812).
With many ignores (a few thousand) /reload could take so long that connections
were dropped. The problem is that nickmatch_rebuild() was being called for
every ignore. The easy solution is to only call it once at the end.
this fixes a crash due to illegal memory access that can occur if
something is printed to the screen on the "terminal resized"
handler. It is not clear to me whether this race condition can be
triggered by external incoming messages, but it might be better safe
than sorry.
