The default behavior was to announce feeds on all channels with the same name,
which is rarely what was expected.
Instead, this limits it to the current network.
Until now, only `waitingJoins` was stored separately per network, while
`channels`, `sentGhost` and `identified` had one common value per plugin
instance. Instead of making everything a dictionary indexed by network
name like `waitingJoins`, let's bundle all the state together in a class
and store *its* instances in such a dictionary.
This fixes at least one race condition, for which a test case was added.
Even with `noJoinsUntilIdentified` set, the bot would let joins through
as long as *any* one network has already finished identifying.
I didn't observe any error with the current set of tests but adding
another one that used "services password" caused oen of these tests
to fail. Given that tests shouldn't leave traces in global state,
let's reset the configured passwords in finally blocks.
by moving the 'smart' reply() method from NestedCommandsIrcProxy
to ReplyIrcProxy.
There is no reason only commands should have a paginated output
and not snarfers defined in PluginRegexp.
Starting with this commit, there should be no "original" text
in READMEs.
Instead, the entire text should be in docstrings, and READMEs
should be automatically generated from these docstrings.
Motivation:
* The same help is available both via IRC and in the README
(although the README can be more detailed, as only the first
paragraph will be shown on IRC)
* This will allow auto-generating plugin help on docs.limnoria.net
using the same content as the README, as it's sourced from the
docstrings
Additionally, this converts all READMEs from Markdown to ReST,
because the documentation already uses ReST, and other docstrings
in the codebase are in ReST for this reason.
Many people are renaming their default branches from master to main or
something else (I just renamed mine). Using HEAD works no matter what
the default branch is named.
Sometimes (very rarely), the test errors with:
```
======================================================================
FAIL: testHistsearch (Aka.test.AkaChannelTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/supybot/test.py", line 214, in runTest
originalRunTest()
File "/usr/lib/python3/dist-packages/supybot/plugins/Aka/test.py", line 67, in testHistsearch
self.assertResponse('histsearch .*', '@echo foo')
File "/usr/lib/python3/dist-packages/supybot/test.py", line 402, in assertResponse
self.assertEqual(m.args[1], expectedResponse,
AssertionError: '@aka add histsearch "last --from [cif true[80 chars]"]]"' != '@echo foo'
- @aka add histsearch "last --from [cif true \"echo test\" \"echo test\"] --regexp [concat \"m/$1/\" [re s/g// \"@2\"]]"
+ @echo foo
: '@echo foo' != '@aka add histsearch "last --from [cif true \\"echo test\\" \\"echo test\\"] --regexp [concat \\"m/$1/\\" [re s/g// \\"@2\\"]]"'
```
ie. histsearch returns the 'aka add' message instead of the 'echo foo'
one.
My guess is that if they happen too closely to each other, they get
added to the history in the wrong order (how? it's not threaded)
So this commit works around the issue by making the regexp unambiguous.
_sendToOthers expects msg.channel to be 'in otherIrc.state.channels',
but IrcMsg objects don't have their 'channel' attribute set until they
are passed through irclib, so it was left unset, which means messages
were never sent at all.
Regression introduced in c1ae3f5c81.
"Search not found in the last X *messages*" is a bit confusing because this is really counting the entire history, which includes all other lines of IRC communication (this means pings, /NAMES replies and so on).
Reported by fred` at #limnoria.
This adds a new message tag applied to all messages SedRegex has seen, in addition to the one for marking messages parsed as a regexp.
SedRegex will now look through the message history and check that all messages without the "seen" tag are not in fact a regexp, before
marking it as seen so that it doesn't do repeated work.
This is a safe command for admins to allow as it's limited to text reminders,
unlike the equivalent scheduler.add (+ misc.echo) which usually needs to be
restricted to prevent abuse
It showed 'Not replying to <command> in None,', since channel is None in
private (unlike the former msg.args[0], which was the bot's nick).
I wasn't careful enough when I replaced msg.args[0] with msg.channel
across the codebase.
I disallowed it in f3f628ddba because they
couldn't be deserialized properly.
This commit adds a new 'phrases' config var in addition to 'words',
that is comma-separated instead of space-separated.
The former code worked only with emulated echo-message, as it depends
on internal tags.
In case echo-message (and labeled-response) is enabled, rely on
remembering the label instead.
With a custom (globally-configured) user-agent, Google may serve a different page, which breaks this plugin.
This override disables this custom user-agent and uses a predefined one, which is known to work.
