Multiple patches

[ShadowNinja]

This combines a number of my pull requests and future commits will be added to it to prevent flooding the issue list.

To do:

• Add RPL_ISUPPORT parsing.
• Allow hooking to any IRC command.
• Save the server's MOTD.
• Add support for arbritrary status modes via ISUPPORT PREFIX.
• User and channel mode saving. (Means rather complicated mode processing functions...)
• Add Message class
• Use Message objects internally and pass one to Do* hooks.
• Pass the Connection to hooks? (Breaks compatability)
• Add support for IRCv3 tags.
• Add proper CAP parsing.
• Add SASL support?
• Add support for IRCv3.3+ JSON IRC (after a standard is released)
• Switch to Lua 5.2 module format (potentially incompatible)
• Add a message queue.

[JakobOvrum]

I added Travis continuous integration for automatically pushing changes to the documentation. It hadn't been updated for years and it's a pain to do it manually. Another upside is that if a test-suite of some kind is added, it will be trivial to integrate it with Travis.

Anyway, what do you want me to do about the recent PRs? Do you want to merge just this big one when it's all ready? Just ping me whenever.

[ShadowNinja]

@JakobOvrum: Nice to see you again. :-)
This should be mergable (or rebasable) now, the only compatability-breaking change is a change in a feature added in a previous commit in this PR (pass Message to Do* hooks).
Note that I've added the original version of my queue pull. This is fully backward compatible and does not result in double-queueing or the like. meta:send still sends messages immediately and you aren't required to use the queue at all, although I'd recommend it.
This does, however depreciate the old way of sending messages, namely by using raw RFC1459 strings. Message objects sgould be used. The msgs table contains constructors for some common messages. Eg:

conn:send("PRIVMSG %s :%s", target, text)
-- New way:
conn:queue(irc.msgs.privmsg(target, text))
-- Or:
conn:queue(irc.Message("PRIVMSG", {target, text}))

This allows for easy future extension to other IRC protocols, such as a JSON-based one.

Once this is merged I'll close my other pulls (or you can).

I checked your commits and noticed that they hardcode the owner and reop names. I find luadoc hard to use, but maybe a little reading will help...

Also: Is there a IRC network that you frequent? Or at least some communication method more appropriate than GitHub issues? I'd like to be able to disscuss things more real-time.

[JakobOvrum]

This does, however depreciate the old way of sending messages, namely by using raw RFC1459 strings.

The send method is just intended as a convenience until the interface is more fleshed out. For PRIVMSG there has always been sendChat.

Note that I've added the original version of my queue pull. This is fully backward compatible and does not result in double-queueing or the like.

It has all the problems I mentioned in the other PR. Only messages that are triggered by the user should be queued, and even then it must be optional.

I checked your commits and noticed that they hardcode the owner and reop names. I find luadoc hard to use, but maybe a little reading will help...

That's intentional. The encrypted Github access token in .travis.yml is only valid for JakobOvrum/LuaIRC, so the publishing script ends early for other repositories (like forks) so it won't count as a failed build if they choose to set up Travis as-is.

LuaDoc is a bit of a pain, but now that there are scripts that are run automatically, developers won't have to touch it unless it's a fork they don't intend to push upstream to JakobOvrum/LuaIRC (and in that case, the scripts show how it's done anyway).

Also: Is there a IRC network that you frequent? Or at least some communication method more appropriate than GitHub issues? I'd like to be able to disscuss things more real-time.

I'm jA_cOp on FreeNode, where I participate in numerous channels, including #lua.

[JakobOvrum]

Pass the Connection to hooks? (Breaks compatability)

BTW, didn't we talk about this before? The user can easily refer to the connection as an upvalue in the callback function.

[ShadowNinja]

It is of course possible to get the connection by wrapping every hook and a wrapper for every connection, like I do here. But passing it from the library would be much cleaner.