If the server didn't send it then just skip the check, the old value it
defaulted to was possibly overlapping with the CHANTYPES leading to an
incorrect behaviour. Fixes#435.
Turns out event_names_list() in irc-nicklist.c already handles this.
event_who() just ignores it, which is probably a good idea since some of
the irc servers I tested this with have a bug that results in sending
multiple prefixes in the NAMES reply but not in the WHO one (they were
forks of ircd-hybrid before 7.3.0)
And NAMES always happens, anyway. WHO is omitted sometimes for huge
channels.
The only supported methods are PLAIN and EXTERNAL, the latter is untested as of
now.
The code gets the values from the keys named sasl_{mechanism,username,password}
specified for each chatnet.
The function now skips all the leading characters that are in the STATUSMSG. If
the server didn't send the STATUSMSG option then it's assumed to be "@+" for
compatibility with bahamut 2.4 (sic).
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).
ferret, the author of `splitlong-safe.pl' pointed out that `userhostlen'
should not only contain the maximum length of the hostname, but also the
maximum length of the username. Now 10 is used as the maximum username
length as a fallback. (`splitlong-safe.pl' uses the same limit.)
The username limit isn't defined in the standard, but 10 is common on
many networks. The odds that something goes wrong here is low, as
1) the fallback limit is only used when the user has not yet joined a
channel
2) the maximum hostname length (63) gives some error margin as the
hostname usually is shorter
`split_line_end' could force lines to be unnecessarily split. This
commit fixes the problem by making sure that the last line isn't shorter
than `split_line_end'.
Add settings `split_line_start' and `split_line_end' analogous to
`splitlong_line_start' and `splitlong_line_end' in `splitlong.pl'. The
prefixes and suffixes are concatenated with a wrapper function to keep
`recode_split' and `strsplit_len' simple.
This commit adds handling of long IRC messages to the core. In contrast
to the `splitlong.pl' plugin, multi-byte encoded and recoded messages
are properly split.
To allow for this, a new function has been added to the server struct:
`split_message'. `split_message' returns a string array with the message
splitted to substrings of a length that the server can handle. If a
protocol module doesn't have any limit, it can simply return a singleton
array with a copy of the message.
The `MSG' chat command now calls `split_message' before `send_message',
and emits `message own_public' / `message own_private' with each
substring, so that the string splitting will be visible in the UI.
`split_message' in the IRC module uses `recode_split' which in turn uses
iconv to properly split multi-byte encoded (and recoded) messages.
Use g_string_append_printf() instead of g_string_sprintfa() (which is considered deprecated.)
git-svn-id: file:///var/www/svn.irssi.org/SVN/irssi/trunk@5003 dbcabf3a-b0e7-0310-adc4-f8d773084564
message own_{private,public} now receive the message in the client encoding.
git-svn-id: file:///var/www/svn.irssi.org/SVN/irssi/trunk@4890 dbcabf3a-b0e7-0310-adc4-f8d773084564
function to read linewise from the associated io channel.
Rewrite irc/dcc/proxy read logic on top of it.
git-svn-id: file:///var/www/svn.irssi.org/SVN/irssi/trunk@4841 dbcabf3a-b0e7-0310-adc4-f8d773084564
The -usermode is now implicitly treated as a requested
usermode change; the MODE command setting it is not
redirected. This is good because user MODE may or may
not give a reply and this could be confused with the MODE
message indicating the initial usermode.
Possible issue here: '-' modes in -usermode persist only
until you change your umode via /mode.
Bug #548
git-svn-id: http://svn.irssi.org/repos/irssi/trunk@4668 dbcabf3a-b0e7-0310-adc4-f8d773084564
We do not do this for WHOIS because the resulting replies
tend to be buggy and inconsistent.
git-svn-id: http://svn.irssi.org/repos/irssi/trunk@4617 dbcabf3a-b0e7-0310-adc4-f8d773084564
"Bad user info" (case insensitive) in an ERROR message as
an indication of a server ban.
git-svn-id: http://svn.irssi.org/repos/irssi/trunk@4571 dbcabf3a-b0e7-0310-adc4-f8d773084564
