should fetch the xkcd by number

The reaction stuff and PEP mentions currently don't work in them 😩

Floats are a bit unreasonable for these discrete values

https://beta.ruff.rs/docs/faq/#how-does-ruffs-import-sorting-compare-to-isort
https://beta.ruff.rs/docs/rules/#isort-i
https://beta.ruff.rs/docs/settings/#isort

This can be done without using miru as well.

I just realized that some plugins are using crescent.Plugin, while others are using the one located in utils/. That should be fixed, and while we're at it, I think it should be moved.

These are the tasks I have in mind, idk if we want to do all of them or not.

• Move utils.plugin:Plugin to plugins._plugin:Plugin
• Always use the subclassed version of the plugin
• Add a custom context that also casts the type of bot

• Add an option to allow the default link embed in the /pep command
• During detection for a message with pep in it, instead of sending links, send one embed listing all PEPs that were mentioned and their respective links.

nah, but I was thinking about making the entire reply an embed so you can have hyperlinks when multiple PEPs are mentioned maybe

Originally posted by @trag1c in #39 (comment)

So I don't have to SSH every time to update the bot.

Everyone with the Patron role should receive the Donor role, and the bot does somehow do that, but it seems like the bot needs to be online when the user gets the Patron role, so if the bot is offline and a user gets Patron, the user will not get Donor, like, ever.

My suggestion is for the bot to, on a programmed schedule (every day should be more than enough), look at everyone on Patron and make sure they're also on Donor.

Using fuzzy search, allow searching for mCoding videos by their title and/or description.

The /pep command can have two optional arguments:

• number
• query

You must specify exactly one option. Number just returns that pep, whereas query will use fuzzy searching to search the peps by their titles. This is also the easiest way to introduce fuzzy searching to the codebase.

We should re-implement the autopublisher. Should listen for messages in #announcements. If they match a youtube video regex, it should automatically publish them.

You can this info from the pep dict with the key "superseeded"

It would be cool to have a slash command for searching sphinx documentation. All sphinx docs generate an object.inv file, which can be downloaded, parsed, and cached.

For example, the python docs: https://docs.python.org/3/
The objects.inv file is: https://docs.python.org/3/objects.inv

I found some great documentation on how to parse this https://sphobjinv.readthedocs.io/en/latest/syntax.html. Once parsed, it can be cached, and then we can probably use some sort of fuzzy search. The cached version of documentation can be set to expire after 24 hours.

For the slash command, I was thinking something like this:

/rtm query: <query> [docs-url: <docs-url="https://docs.python.org/3/">]

The docs-url can have autocomplete (and we can list more common projects), but will let you specify any valid sphinx url. If the url hasn't been used yet, it'll download/parse/cache it first.

• /lookup-pep command

This command will take an option witch has a fuzzy search autocomplete to find a pep by name.

An issue with highlight relevance

Glossary

• notification: private message from the bot about the highlighted word.
• TM: triggering message, i.e. that contains an highlighted word.

Synopsis

Let's say user A has cat in their highlighted words list.

If user B sends a message containing cat, user A will receive a notification about the TM.

However, if user B edits their message, it could happen not to contain the word anymore, making the notification irrelevant. This also means that the user A has access to the previous version of the message^[1], which can have serious implications, that will be discussed further.

Concerns

If cat is a pretty innocent substantive, an edge case subsists where the user B sends a rule-breaking TM. The message would have been deleted, but the user A will still be exposed to its contents through the notification.

For instance, the current rules prohibit hate speech^[2]. This means that one having a highlighted list is potentially exposing themselves to content they might did not want in the first place.

Proposal

TM tracking

TMs could be tracked for a given period of time -- if they get deleted, or edited, the bot can behave accordingly, removing the notification if needed.

One limitation of this proposal I can think of is that the ping of this notification is likely to stay (ghost ping).

An alternative could be that instead of deleting the notification, it would edit into saying something like: "This message has been edited/deleted".

To go further

While writing this, other ideas of features emerge in my mind. This is the part where I list them.

Word matching rather than character sequence

Currently, if one have java as a highlighted word, a message containing "javascript" is a TM.

It should preferably use pattern matching rather than a simple word in message^[3].

Channel-dependent highlights

I think it would be a very nice feature if we could add/remove specific channels for a given highlight -- although, the highlight create command should by default set up the highlight for every channel.

Allow close-enough to trigger

User B could mistype a word, but user A would still want to get a notification for it.

This idea is kind of mutually exclusive with this one, because I am not sure how to mix pattern matching and levenshtein distance thresholding.

Inhibitors

Inhibitors would be words that prevent a message from being TM even if they contained a highlight.

For example, if you have rust as a highlight and javascript has an inhibitor:

• "I like Rust" => TM
• "I like Rust and JavaScript" => not TM
• "I like JavaScript" => not TM

To go further, make inhibitors highlight-dependent -- one inhibitor would have an effect on a specific highlight but not on any other.

Highlight temporary deactivation

One could want not to get notifications for a word for a certain time frame.
This idea is at the very bottom because it might have a real-world purpose.

Notes

Note 1

That also implies that the user A would have access to contents that the user B deliberately decided to modify. Does this have legal implications? ^[↑]

Note 2

Rule 9 links the Discord guidelines: https://discord.com/guidelines. ^[↑]

Note 3

https://github.com/mcb-dev/mCodingBot/blob/main/mcodingbot/plugins/highlights.py#L201. ^[↑]

Tasks are just another kind of plugin. Since we already have some tasks inside the plugins folder, I think it would be best to put the stats "task" plugin under plugins.

cc @trag1c @Lunarmagpie