| Age | Commit message (Collapse) | Author |
|---|
|
A test to try to get _something_ to compile. And it does!
Here we try to run a plugin with `runReaderT` and `runBot` to pass
`Options` to the plugin, using the "help" plugin as an example. It feeds
hard-coded `Options` to the plugin and outputs its response to STDOUT.
Also get an implementation of `initializePlugins` working that will
allow us to build a list of plugins with `Options` applied to the
reader.
This commit comments out the whole of IRC.hs in order to get the code to
compile. That file still has a bunch of `Bot` monad-related type errors.
To build the final plugin list, I think what we'll want to do is use
something like `initializePlugins` in Lib to apply all our plugins with
the `Options` and then feed that to `connectIRC`. In order to build the
"help" plugin, the plan is to re-apply the `Options` after `ask`ing for
them inside the `PluginAction` for "help" to all plugins, thus enabling
us to get a plugin list with the applied reader for proper localisation
of the help output.
|
|
The plugin list's type has changed from `[Plugin]` to `[Bot Plugin]`. In
order for our code here to work, we need to unwrap the `Bot` part so we
can get access to the `Plugin` again and do the same work.
Fortunately, using `sequence`, we can turn our `[Bot Plugin]` into a
`Bot [Plugin]`, which is then easily bound with `<-` and passed to our
old code to be handled like before. Yay!
|
|
Add our `Bot` monad to the rest of the plugins:
* Factorial
* GitRemoteSetOrigin
* Help
The only problem is with the Help plugin. Still trying to figure out how
to set up my list comprehension so that it works with the `Bot`-wrapped
`Plugin` list.
|
|
If the plugin is defined as `queryOnly`, the response shouldn't be sent
on the channel to everyone, it should instead be sent directly to the
user in a private query message.
Enable this functionality for the Help plugin so that help output only
gets sent to the user requesting help. This ensures other channel
participants don't get an annoyingly long section of output that they
didn't ask for.
|
|
A new field that says whether this plugin should only respond via a
private query message to the user instead of responding on the channel
the message was sent from.
This is needed for the Help plugin, which shouldn't flood channels with
lots of extraneous output. Instead, the Help plugin should send the list
of commands directly to the user.
Since most of the time we don't want this behaviour, encode a default of
`False` on the field so that most plugins don't have to define it
manually. This necessitates changing the constructors to use the default
`Plugin` instead.
|
|
Asking for `Plugin.Plugin...` is redundant. Take this module out of the
`Plugin` directory to eliminate the repetition in naming.
|
|
To aid the readability of the help output, align the dashes vertically
so the descriptions are in a uniform place.
The resulting output now looks like this:
<git_sha> – Generate a commit URL based on the given SHA.
git remote set origin URL – Set the git remote URL for this channel.
help – Show a list of available bot commands.
|
|
Instead of printing all help text on a single line as a result of
joining the list of help text, print each plugin's help on a separate
line.
Also separate commands from descriptions with a dash instead of a tab as
the tab character was getting rendered as an `I` in irssi instead of the
actual whitespace I had been hoping for. The dash in inspired by Hubot.
In order to print multiple lines of output, we needed to change the IRC
PRIVMSG handler. This now splits the plugin result at newlines into a
list and sends separate PRIVMSGs for each line of output. Before, text
with newlines would only show the first line in the resulting IRC
message.
Assume plugin error messages will always be a single line.
|
|
A new plugin that displays a help listing for every plugin in the bot.
Currently the formatting is off in the chat output, but it does work.
This introduces two new record fields on `Plugin`: `command` and
`description`. The command is the text used to invoke the plugin and the
description is a long form explanation of what the plugin does.
Needed to update the `Show` for `Plugin` to match these extra fields.
Didn't change any of the output for now because I'm not really using the
`show` function, so I don't need to see the new fields for now. Also
change the `p` argument to an `_` because we're not using it.
All existing plugins now have the new fields filled. The Help plugin
will go through the list of all plugins and get their help fields for
output.
In order to be able to use the plugin list in both `Plugin.hs` and in
the Help plugin module, I needed to move the list into a new module to
avoid a circular dependency. Previously the `Plugin` module defined the
list, but we can't import `Plugin` from `Help` because `Plugin` needs to
import `Help` in order to build the full list of plugins. The
semi-hackish solution I came up with was to create a new module for the
plugin list that both these modules can use, but leave out the `Help`
plugin from the plugin list there. Then, `Plugin` and `Help` override
the list, appending the `Help` plugin to the list. I want the Help
plugin to appear last, which is why I'm appending. Wasn't comfortable
concatenating the list because of the performance smell, but it's going
to be a small enough list anyway that it shouldn't be a problem.
One thing I don't really like is the fact that we have to return an
`IO a` from `helpAction` even though it doesn't interact with `IO` at
all. Not sure if there's a way to use `IO` when we need it and not when
we don't. Not a huge deal though.
|
