Have a ignore_find_full method that is the one that all the new code
should be using and provide some working stubs for ignore_find and
ignore_find_noact.
This way we prevent the creation of duplicate ignores since the old code
skipped the ignore_find call when a pattern was specified.
It should also cover all the cases where the ignores would be wrongly
overwritten, such as the case outlined in #78.
With bracketed paste, "a\nb" will result in two lines being pasted,
because it's a single thing, with an end marker which the timeout based
pastes don't have.
Due to the way term_gets() counts lines, that input will have
paste_line_count == 1. This can be misleading.
This code adjusts it by looking at the last character, and increasing
the count if it finds anything that isn't a newline.
Issue #340 brought to our attention the fact that under certain
circumstances irssi would go on a wild rampage and carelessly overwrite
some saved channel records in the configuration file.
This happened because the code didn't take into account the case where
the channel index in setupchannels wouldn't match the one in the
configuration; this actually happens when the user removes a chatnet
without removing the associated channels.
Turns out it confuses inspircd, making it reply a NAK with empty
parameter. The rest is ACKed anyway. I've already whined at saberuk
and there's a pending pull request over there fixing this issue.
And, of course, this is cleaner.
This fixes a long-standing bug where 'fname' was being feed to cat
instead of 'real_fname', causing it to quit with a 'No such file or directory'
error.
FS#377
The function "static void paste_buffer_join_lines(GArray *buf)" in
"src/fe-text/gui-readline.c" is supposed to join lines from the GArray
pointed to by *buf under certain circumstances.
In the code of the function "buf" is actually used for getting the length
of the GArray, but to get a pointer to the data, "paste_buffer->data" is
used; paste_buffer is defined in the scope of the whole file.
This delivers the desired result, because this function is only called
once, with "paste_buffer" as the argument. If paste_buffer_join_lines()
will ever be used with a different argument, it will fail.
The symptom for this one is randomly getting lines split before the last
word, even if there's no need for splitting. Also, this function is only
reached if recode is on, and iconv failed (for example, due to an
incorrect source charset). Thanks to vague for finding this and
providing valgrind logs.
The loop that looks for spaces tried to read backwards from the end of
the current line, with the end being determined by len. Assuming
strsplit_len() with len=400, this meant accessing str[399] in the first
iteration. For strings that don't need splitting, this means an invalid
read always.
If that invalid read happens to hit garbage that has a space character,
(len - offset) points after the end of string, which isn't a problem for
g_strndup() since it stops at the first null, and no splitting happens.
If the garbage doesn't have any spaces, it splits by the last word.
This commit avoids that loop entirely if (remaining_len > len). It also
changes the way it iterates over the string to be much less confusing.
Turns out it was fixing the wrong string, and trying to do
atoi("RECON-1") instead of atoi("1").
"/reconnect 1" worked, but "/reconnect RECON-1" gave that confusing
error message.
Given a big enough write_buffer_size and a long enough
write_buffer_timeout it might be possible to show the user an incomplete
or empty awaylog.
Patch by: Petteri Aimonen
term_addstr() had a long-standing fixme that suggested it didn't
take into account the string encoding when calculating the string
length.
The BIG5 code path is untested.
Both cases were off-by-one mistakes erring on the side of being too
conservative. This fixes these two harmless issues:
- For a single empty paste, it required another keystroke before
processing it
- For a sequence of themcase, a single '~' was left in the input
This actually workarounds a bug with the "st" terminal, for which i've
already submitted a patch, but irssi needs to be able to handle it
decently too.
