<h1>Stupid-Simple Spell-Check</h1>
<img src="/images/antiques.webp" alt="A sign advertising for antiques, but misspelled.">
For the last month, I’ve been spend­ing a lot of time re­plac­ing one key com­po­nent
of my writ­ing and pro­gram­ming en­vi­ron­ment: my gram­mar checker.
Up un­til now, I’ve been us­ing the epony­mous <a href="https://languagetool.org/">LanguageTool</a>
via <a href="https://github.com/valentjn/ltex-ls"><code>ltex-ls</code></a> and <a href="https://github.com/neovim/nvim-lspconfig"><code>nvim-lspconfig</code></a>.
Don’t get me wrong, these tools are re­ally good, and I would rec­om­mend them to any­one and every­one.
How­ever, they come with a few key an­noy­ances.
<h2>LanguageTool Grievances</h2>
<h3>Performance</h3>
LanguageTool is slow.
I’m not ex­actly sure why.
Every time I would run LanguageTool over my Markdown or <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mtext>LaTeX</mtext></mrow><annotation encoding="application/x-tex">\LaTeX</annotation></semantics></math>LATE​X doc­u­ments (which are rea­son­ably sized),
I would have to wait sev­eral sec­onds be­fore even the rudi­men­tary spell-check­ing would show up.
Additionally, I would ﬁnd <code>ltex-ls</code> reg­u­larly be­com­ing the most mem­ory-hun­gry ap­pli­ca­tion on my lap­top,
of­ten ex­ceed­ing 4 gi­ga­bytes.
After hours of scour­ing their code base, I have come to no bet­ter ex­pla­na­tion
than that it is writ­ten in Java.
There are a cou­ple ques­tion­able al­go­rith­mic de­ci­sions in there as well.
<h3>Download Size</h3>
As I said: LanguageTool is re­ally quite good.
How­ever, to get every­thing it can of­fer, you need to not only in­stall a Java Runtime
Environment (>150 MB on my sys­tem), the ac­tual <code>.jar</code> ﬁle (>300 MB), but you also need to down­load
a 16 GB n-gram dataset.
<h2>Grammarly Grievances</h2>
“But Elijah,” I hear you say, “just use Grammarly!”
No. I’m not go­ing to drop $12 a month for some­thing even slower and worse.
Not to men­tion how they are likely go­ing to use my work to train their large lan­guage mod­els.
Gram­marly is a great prod­uct, just not for me.
<h2>The Algorithm</h2>
Now that I’ve thor­oughly ex­plained my rea­son­ing for im­ple­ment­ing a new gram­mar checker (one that I’m call­ing <a href="https://github.com/elijah-potter/harper">Harper</a>), I’d like to re­count
my ﬁrst, ad­mit­tedly naive, at­tempt at spellcheck­ing.
The ﬁrst idea we need to get a grip on is Levenshtein edit dis­tance.
In essence, edit dis­tance is the least num­ber of sin­gle-char­ac­ter ed­its (insertions, dele­tions or re­place­ments) nec­es­sary to turn one word into an­other.
For ex­am­ple, the edit dis­tance be­tween “cat” and “bat” is one; the only edit in­volves re­plac­ing the “c” with a “b”.
Similarly, the edit dis­tance be­tween “kitten” and “sitting” is three: re­move the “g”, re­place the sec­ond “i” with an “e” and re­place the “s” with a “k”.
For this naive spellcheck­ing, we aren’t too con­cerned with the ex­act ed­its (atomic er­rors) that oc­cur in a given mis­spelling, only the mag­ni­tude of the er­ror.
From a high level view here’s how the al­go­rithm is go­ing to work:
<ol>
<li>Determine whether a given word is mis­spelled.
If not, exit.</li>
<li>Calculate the Levenshtein edit dis­tance be­tween the mis­spelled word and all valid English words.</li>
<li>Pick the three words with the short­est edit dis­tance and pre­sent them to the user as al­ter­na­tive
spelling op­tions.</li>
</ol>
<h3>Step 1.</h3>
To de­ter­mine whether a given word is mis­spelled, we will need a list of all the valid words in the English lan­guage.
Turns out, this is­n’t too easy.
For to­day, we will just use a sub­set of the English lan­guage with this short list:
<pre><code>into
the
a
cat
tree
jumped
</code></pre>
To check if a given word is within the list, we can place the list into a hash set,
and grab it’s con­tents.
<pre><code class="hljs language-rust">let words: Vec&#x3C;String> = vec!["into", "the", "a", "cat", "tree", "jumped"]
 .into_iter()
 .map(|s| s.to_string())
 .collect();

let word_set: HashSet&#x3C;String> = words.iter().cloned().collect();

let word = "thw";
let word_chars: Vec&#x3C;_> = word.chars().collect();

if word_set.contains(word) {
 println!("It is a valid English word!");
 return;
}

println!("Are you sure you meant to spell \"{}\" that way?", word);
</code></pre>
<h3>The Wagner-Fischer Algorithm</h3>
Now that we know our word is ac­tu­ally mis­spelled, we can move on to ﬁnd­ing the cor­rect spelling.
We need to ﬁnd the edit dis­tance be­tween the mis­spelled word and all the words in our set.
To do this, we will be us­ing the <a href="https://en.wikipedia.org/wiki/Wagner%E2%80%93Fischer_algorithm">Wagner-Fischer</a> al­go­rithm.
<pre><code class="hljs language-rust">// Computes the Levenstein edit distance between two patterns.
// This is accomplished via the Wagner-Fischer algorithm
fn edit_distance(source: &#x26;[char], target: &#x26;[char]) -> u8 {
 let m = source.len();
 let n = target.len();

 // Create an m-by-n matrix.
 let mut d = create_empty_matrix(m + 1, n + 1);

 // Since we know we can transform each word into the other by replacing
 // successive characters (or deleting them), we can fill the first column and
 // row with values from 0..m and 0..n, respectively.
 for i in 0..=m {
 d[i][0] = i as u8;
 }

 for i in 0..=n {
 d[0][i] = i as u8;
 }

 for j in 1..=n {
 for i in 1..=m {
 // The total edit distance of two given letter indices i and j, one from each word
 // will be the sum of the edit distances of prior combinations + whether the characters
 // at the two indices are equal.

 let cost = if source[i - 1] == target[j - 1] { 0 } else { 1 };
 d[i][j] = (d[i - 1][j] + 1)
 .min(d[i][j - 1] + 1)
 .min(d[i - 1][j - 1] + cost);
 }
 }

 // After all possible edits have been explored and minimized
 // the resulting minimum edit distance will be in the final item in the matrix.
 d[m][n]
}

// Create an empty matrix of size [m, n]
fn create_empty_matrix(m: usize, n: usize) -> Vec&#x3C;Vec&#x3C;u8>> {
 let mut d = Vec::with_capacity(m);

 for _ in 0..m {
 d.push(vec![0u8; n]);
 }

 d
}
</code></pre>
This works pretty well.
There are a num­ber of op­ti­miza­tions we could ap­ply to this func­tion alone.
I’ll leave that as a prob­lem for the reader, since they aren’t par­tic­u­larly rel­e­vant to the meat of the larger al­go­rithm.
<h3>Steps 2 + 3</h3>
Now that we can de­ter­mine the edit dis­tance be­tween two words, we can per­form a brute-force search.
In this short ex­am­ple, we’re go­ing to use <code>sort_by_key</code> to do this, since our data set is so small.
If we were work­ing with a larger dic­tio­nary (say, the en­tire English lan­guage), there would be a num­ber of things we would need to do to re­duce time and mem­ory con­sump­tion.
<pre><code class="hljs language-rust">let mut suggestions: Vec&#x3C;(String, u8)> = words
 .into_iter()
 .filter_map(|possible_word| {
 let possible_chars: Vec&#x3C;_> = possible_word.chars().collect();

 let dist = edit_distance(word_chars.as_slice(), &#x26;possible_chars);

 if dist &#x3C;= 2 {
 Some((possible_word, dist))
 } else {
 None
 }
 })
 .collect();

suggestions.sort_by_key(|(_, d)| *d);

println!("Possible alternatives: ");

suggestions.iter().for_each(|(s, _)| println!("- {}", s));
</code></pre>
If we run the whole pro­gram again, we get an out­put some­thing like:
<pre><code class="hljs language-output">Are you sure you meant to spell "thw" that way?
Possible alternatives:
- the
</code></pre>
That looks pretty good to me!
If you would like to look at the whole pro­gram, and maybe try out your own in­puts, <a href="https://play.rust-lang.org/?version=stable&#x26;mode=debug&#x26;edition=2021&#x26;gist=fb7910ad1fb3a6c944cbc2ae8659bb31">go right on ahead</a>.

It al­most feels wrong. Maybe it is.

Stupid Simple Spell Check

<h1>How to Write a Discord Bot in Rust</h1>
Discord is an in­stant mes­sage plat­form with more than 150 mil­lion monthly ac­tive users. The main ap­peal seems to a com­bi­na­tion of the wide reach that plat­forms like StackOverﬂow have, as well as the in­stant de­liv­ery of the in­stant mes­sag­ing con­cept. One of the best fea­tures of Discord is it’s seem­ingly un­lim­ited hack­a­bil­ity of the plat­form via it’s “Bot” sys­tem. The Bot sys­tem al­lows de­vel­op­ers to add func­tion­al­ity to Discord com­mu­ni­ties by writ­ing soft­ware that in­ter­faces in a sim­i­lar way that peo­ple do. I want to give you an in­tro­duc­tion on how to do that in Rust.
<img src="/images/flat_ferris.png" alt="A Flat Render of Rust&#x27;s Mascot, Ferris">
<h2>Interaction</h2>
Most in­ter­ac­tion with Discord bots hap­pens via com­mands, not dis­sim­i­lar to ter­mi­nal ap­pli­ca­tions. Commands may look like <code>!play Eat it by Weird Al</code>.
<img src="/images/ping_pong.png" alt="Ping! Pong!">
The bot we are go­ing to make now will sim­ply re­spond to <code>!ping</code> with “Pong!”.
<h2>Template</h2>
<img src="https://github.com/elijah-potter/discord-bot-template" alt="cargo generator template">
<h2>Setup the Project</h2>
Using a func­tion­ing Rust en­vi­ron­ment, use cargo to cre­ate a new pro­ject. E.g:
<pre><code class="hljs language-bash">cargo new tutorial-bot
</code></pre>
Next, we have to add <a href="https://github.com/serenity-rs/serenity">Serenity</a>, the li­brary for cre­at­ing Discord bots in Rust. We also have to drop in Tokio, be­cause Serenity takes ad­van­tage of it’s async run­time.
You can do this ei­ther via cargo-edit:
<pre><code class="hljs language-bash">cargo add serenity
cargo add tokio --features full
</code></pre>
or by just adding them to Cargo.toml:
<pre><code class="hljs language-toml">[dependencies]
serenity = "0.10.5"
tokio = { version = "1.5.0", features = ["full"] }
</code></pre>
<h2>Setting up the Standard Framework</h2>
Serenity has a lot of ﬂex­i­bil­ity. You have ac­cess to a event han­dler that al­lows ﬁne grain con­trol of events. You also have ac­cess to a stan­dard frame­work that makes it ridicu­lously easy to re­spond to com­mands.
Be­fore we do any­thing else, we have to make our main func­tion async. It is su­per easy to do that, just re­place it with:
<pre><code class="hljs language-rust">#[tokio::main]
async fn main() {
}
</code></pre>
First, we want to get our bot to­ken in. In an ac­tual bot, please ob­tain it via an en­vi­ron­ment vari­able or some other method. We are only do­ing it this way for sim­plic­ity.
<pre><code class="hljs language-rust">let token = "{your bot token}";
</code></pre>
If you do not know how to get a bot to­ken, please fol­low <a href="https://www.getdroidtips.com/discord-bot-token/">this tu­to­r­ial</a>.
The Serenity Standard Framework splits your bot’s com­mands into groups. Each group can have mul­ti­ple com­mands. For ex­am­ple, a bot might have two groups: one fo­cused on fun and one fo­cused on math. The for­mer has com­mands like !meme, while the lat­ter may have var­i­ous math func­tions, like sin!. This is also how we will add com­mands to our bot.
First, add the needed structs and macros to the ﬁle:
<pre><code class="hljs language-rust">use serenity::{Client, client::Context, framework::{StandardFramework, standard::{CommandResult, macros::{group, command}}}, model::channel::Message};
</code></pre>
Next, cre­ate a struct that we will at­tach our com­mands to:
<pre><code class="hljs language-rust">#[group]
#[commands()]
struct HelloWorld;
</code></pre>
Once we have added our com­mands, we will en­ter them into the com­mands sub-macro.
Create an in­stance of <code>StandardFramework</code> and add our group to it. We can also con­ﬁg­ure our com­mand pre­ﬁx now.
<pre><code class="hljs language-rust">let framework = StandardFramework::new()
 .configure(|c|{
 c.prefix("!")
 })
 .group(&#x26;HELLOWORLD_GROUP);
</code></pre>
Notice that we used a ref­er­ence to a sta­tic struct called HELLOWORLD_GROUP in­stead of just adding our group. This is the out­put of the #[group] macro.
Now that we have cre­ated our frame­work, we have to at­tach it to a Discord client.
<pre><code class="hljs language-rust">let mut client = Client::builder(token).framework(framework).await.expect("Could not start Discord");
</code></pre>
Start it.
<pre><code class="hljs language-rust">client.start().await.expect("The bot stopped");
</code></pre>
<h2>Adding the Command</h2>
Now that we have the frame­work set up, let’s add a com­mand.
<pre><code class="hljs language-rust">#[command]
async fn ping(ctx: &#x26;Context, msg: &#x26;Message) -> CommandResult{
}
</code></pre>
This com­mand only needs the Discord clien­t’s Context, the mes­sage that con­tains the com­mand, and re­turns a <code>CommandResult</code>.
 Do not for­get to add the com­mand to the group:
<pre><code class="hljs language-rust">#[group]
#[commands(ping)]
struct HelloWorld;
</code></pre>
If you don’t, it will sim­ply not get run.
We want the bot to re­ply to the !ping com­mand with “Pong!”, so let’s add that to the in­side of the ping func­tion:
<pre><code class="hljs language-rust">msg.reply(ctx, "Pong!").await?;
Ok(())
</code></pre>
<h2>Full Code</h2>
Here is the full code for the bot:
<pre><code class="hljs language-rust">use serenity::{Client, client::Context, framework::{StandardFramework, standard::{CommandResult, macros::{group, command}}}, model::channel::Message};
#[tokio::main]
async fn main() {
 let token = "Your bot token";
 let framework = StandardFramework::new()
 .configure(|c|{
 c.prefix("!")
 })
 .group(&#x26;HELLOWORLD_GROUP);
 let mut client = Client::builder(token).framework(framework).await.expect("Could not start Discord");
 client.start().await.expect("The bot stopped");
}
#[group]
#[commands(ping)]
struct HelloWorld;
#[command]
async fn ping(ctx: &#x26;Context, msg: &#x26;Message) -> CommandResult{
 msg.reply(ctx, "Pong!").await?;
 Ok(())
}
</code></pre>
<h2>That’s it</h2>
If you build and run your app, you should have a func­tion­ing Discord bot!
Seren­ity is an amaz­ing crate and is an ab­solute joy to work with. I hope you learned some­thing. There is a ton more stuff that I did not cover here. Feel free to look at the <a href="https://docs.rs/serenity/latest/serenity/">Serenity docs</a> and ex­am­ples to learn more!

We go through step-by-step how to build a Discord bot using the Rust Serenity Framework.

We go through step-by-step how to build a Discord bot us­ing the Rust Serenity Framework.

How to Write a Discord Bot in Rust

<h1>The Simplest Neovim Markdown Setup</h1>
I am not one who en­joys com­plex­ity.
I am also some­one who likes to make their <a href="https://github.com/elijah-potter/harper">own tools</a>.
As a stu­dent, I write a lot.
That in­cludes notes, pa­pers, and doc­u­men­ta­tion for my wide va­ri­ety of pro­jects.
A lot of classes re­quest to sub­mit as­sign­ments as ei­ther PDF, HTML or <code>.docx</code>.
For a while, I sub­mit­ted PDF’s.
I had a whole or­ches­trated setup.
I would write every­thing in <a href="https://neovim.io/">Neovim</a>, save it, and <a href="https://github.com/frabjous/knap">KNAP</a> would ren­der it us­ing <a href="https://pandoc.org/">Pandoc</a>.
Finally, it would be ren­dered to my screen us­ing <a href="https://sioyek.info/">Sioyek</a>.
This worked ﬁne, I guess, but it was far from per­fect.
<ol>
<li>It was slow. Each edit I made in Markdown could take as many as 10 sec­onds to show up in Sioyek.</li>
<li>It was­n’t in­ter­est­ing. While I made mod­i­ﬁ­ca­tions to my Pandoc set­tings, my PDF’s still looked like every other <code>pdflatex</code> doc­u­ment ever made.</li>
<li>I could­n’t make my doc­u­ments in­ter­ac­tive if I wanted to.</li>
</ol>
Markdown was de­signed to be turned into HTML, I rea­soned.
So why not just do that?
<img src="/images/tatum_screenshot.webp" alt="A screenshot of Tatum at work">
That’s why I cre­ated <a href="https://github.com/elijah-potter/tatum">Tatum</a>.
It does one thing, re­ally well.
Point it at a Markdown ﬁle, and it will run a tiny web server to ren­der the re­sult­ing HTML to.
If the ﬁle changes, a WebSocket con­nec­tion tells the browser to re­fresh.
Tatum ren­ders in mil­lisec­onds and cre­ates beau­ti­ful pages with <a href="https://katex.org/"><math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mtext>KaTeX</mtext></mrow><annotation encoding="application/x-tex">\KaTeX</annotation></semantics></math>KATE​X</a>, <a href="https://simplecss.org/">Simple.css</a> and <a href="https://highlightjs.org/"><code>highlight.js</code></a>.
I can em­bed in­ter­ac­tive HTML, CSS and JavaScript el­e­ments di­rectly into my Markdown to get the in­ter­ac­tiv­ity and aes­thet­ics I de­sire.
Once I’m done work­ing, I just run <code>tatum render &#x3C;file.md></code> and I get a sin­gle ﬁle (images and all) that I can sub­mit for my as­sign­ments.
Tatum is­n’t for you to use.
Feel free to poke around at how it works, or even fork it and make your own mod­i­ﬁ­ca­tions.
It ﬁts my use case per­fectly.

How I preview my Markdown quickly and reliably.

How I pre­view my Markdown quickly and re­li­ably.

The Simplest Neovim Markdown Setup

never_wait

<h1>Never Wait</h1>
<blockquote>
Preface: This post is specif­i­cally about Pull Requests for <a href="https://github.com/Automattic/harper">Harper</a>.
Read the con­trib­u­tor guide­lines for a pro­ject be­fore open­ing a PR.
</blockquote>
I get it.
Open­ing a pull re­quest is an in­tim­i­dat­ing propo­si­tion.
It is non-triv­ial to put your blood, sweat, and (let’s be hon­est) tears into code and put that onto the in­ter­net for the world to see.
I re­mem­ber my ﬁrst pull-re­quest: it was­n’t pretty ei­ther.
But I want to high­light a cou­ple rea­sons why I want po­ten­tial con­trib­u­tors to open their pull re­quests as early as pos­si­ble.
<h2>Drafts Reduce Duplicate Work</h2>
When a con­trib­u­tor to a pro­ject is as­sess­ing the vi­a­bil­ity or use­ful­ness of some work they’re prepar­ing to do,
most look at ex­ist­ing Pull Requests ﬁrst.
Even if you’re still work­ing on the patch, it’s a great idea to open a “draft” PR so no one starts work that could go to waste.
Further, if you have a draft open whose CI is fail­ing, a main­tainer may see it and ﬁx what­ever the prob­lem may be.
I ﬁnd my­self fre­quently brows­ing <a href="https://github.com/Automattic/harper/pulls">Harper’s Pull Requests</a> look­ing for fail­ing builds, since I’m of­ten the best equipped to ﬁnd the is­sue.
<h2>It Helps With Debugging</h2>
I try to make my­self avail­able to con­trib­u­tors in case they have any ques­tions re­gard­ing the ar­chi­tec­ture of Harper.
I’m also game to help de­bug their code, partly be­cause I am of the opin­ion that de­bug­ging is a skill which is best learned by ex­am­ple.
But it is hard for me to de­bug code if I don’t have it.
If a draft PR has been opened, I can usu­ally see the prob­lem with­out even cloning the code, since our CI is so com­pre­hen­sive.
<h2>Conclusion</h2>
So please don’t wait; open that PR.
I am thrilled each time I see a name I don’t rec­og­nize on a GitHub no­ti­ﬁ­ca­tion.

Elijah Potter

Never Wait

Drafts Reduce Duplicate Work

It Helps With Debugging

Conclusion

Other Stuff

Stupid Simple Spell Check

How to Write a Discord Bot in Rust

The Simplest Neovim Markdown Setup