Implement !help

[palasso]

We'd have help to print either all help messages when called as !help or print only one message when called as e.g. !help bacon.

It would be easy to add an additional dimension to cmdlist with a string that's supposed to appear when invoking help. We'd change self.cmdlist[out['botcmd']](out,self.usrlist) to self.cmdlist[out['botcmd']][0](out,self.usrlist).

But if we want help to print dynamically help messages for commands then maybe we should make each command return its help message. This would be helpful later with the commands module. For example we'd make bacon(info,usrs,mode) and when help is invoked it would call the method in help mode and do a return of a string (the following commands wouldn't run).
Let's take an example. Let's say we only need 2 modes for a command (it runs the command or it gives command's help as provided by developer of the command). Then instead of mode we'd have a boolean needshelp and the method would be:

bacon(info,usrs,needshelp=False):
    if(needshelp): return("It gives bacon to users")
    ...

We could call this command in help as bacon(info,usrs,True) and get the help for it.
Of course we'd do this for all commands (so we'd list them in an array) or just for this one if we're in the !help bacon case.

Any suggestions? It would be better to decide on the general direction of this before writing code.

[Gamah]

I'm not sure how I'd like to do it quite yet, but it will involve significant breaking changes. This would be a back burner thing until after the commands interface modularized and moved out of the main file.

[palasso]

Ok then, I'll place !help on hold. Let's discuss more on a new issue about the commands module? Not sure what to touch on next.

[Gamah]

The commands module will have to come after refactoring the socket handling and parse method. I took a lot of shortcuts when I first read the IRC RFC's and have run in to some real roadblocks with IRC implementations that gbot does not currently handle correctly.

i'll admit, I'm not even remotely interested in implementing or supporting the full spec (a bot need not to, imo!) but there are some actual blocking differences between common ircd implementations that cause gbot to (presently) be completely unusable on some networks.

I haven't completely fleshed out the new parsing methods in my head, but given what more I have read into the RFC's snice originally writing the bot, I do have a couple good guesses for a "99+%" use case scenario which does not involve the sort of abstraction-hell that I hate seeing in software projects.