| Age | Commit message (Collapse) | Author |
|---|
|
Not totally clear under what conditions 437 is returned, but if it
happens during registration, we should pick a new nick.
|
|
|
|
|
|
"%.*ls" is useless.
|
|
While the automatic search via LESS is neat, I don't think it's very
useful. Just always open the manual to the COMMANDS section, and fix it
to append to LESS rather than replace it.
|
|
Accumulate names in a buffer and show away status.
|
|
It's pretty awkward with large channels since NAMES isn't sorted by
prefixes or anything... But having it accumulate names across many
replies would require more reworking.
|
|
This fixes a bug where if you send a private message before joining any
channels, your message will be routed to the <network> window. That
happens because without a JOIN, self.user remains unset, which means
that require will copy self.nick (set by echoMessage) to self.host. The
easiest solution is to go back to checking for '.' and add a '.' to the
default nick, so now if a server sends a NOTICE with no origin it will
look like -*.*- which is kinda cute.
|
|
|
|
The mention coloring code already matches case-sensitively, and any
proper ping should be using tab-complete anyway so there's no reason for
differing case. And the month of June should not ping me.
|
|
Also determine if a message is from the server by if the host field has
been copied from the nick field.
EFNet sends NOTICEs with no origin during registration.
RFC 1459 has this to say:
> If the prefix is missing from the message, it is assumed to have
> originated from the connection from which it was received.
I suppose a more correct implementation would be to set the origin to
the hostname of the server, but we don't store that globally, so this
is good enough.
|
|
LibreSSL is "a modified version of that library".
|
|
Also the old catf would be broken with -DNDEBUG oops!
|
|
catf is not better though and should really be replaced.
|
|
|
|
|
|
Apparently IRCds have decided that the 15-parameter limit doesn't matter
anymore. 254 is the maximum number of single-byte parameters (following
a single-byte command) which fit in a 512-byte CR-LF-terminated line.
When everyone decides that the 512-byte line length limit doesn't matter
either, I will delete my software and people can use some JavaScript
garbage instead.
This makes struct Message 2080 bytes, but there's only ever one or two
of them around at once. Avoid passing it by value to handle.
|
|
Avoids coloring everything up to a ":)".
|
|
https://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs
|
|
Otherwise they do not work correctly for QUIT and NICK. This also lets
you ignore private messages only by putting the nick in the third field.
|
|
|
|
|
|
I'm sad to do this but I just can't stand writing (foo ? foo : bar)
anymore.
|
|
|
|
I should have been using this for getopt loops already but the call here
is slightly too long to fit on one line as a for loop.
|
|
Going back to one line per mode change again because it's easier.
|
|
Still missing is logging MODE changes, which will be hell, unless it
just logs the raw stuff.
|
|
|
|
The default USERLEN of 9 doesn't have a great source, the RFC only says
that nicks are length 9, so my assumption is that usernames are not
longer.
|
|
|
|
|
|
|
|
|
|
|
|
pounce will start sending these because some silly clients don't think
they're connected until some MOTD reply...
|
|
This intuitively feels wrong, but isn't. Most importantly, handleError
immediately exits, but we still need to "consume" that message,
otherwise pounce will keep sending it on reconnect. The same goes for
any other handler that might cause an exit, such as a require parameter
count failure.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
