codespell: Fix typos caught by codespell.

“Brunch” wasn’t a typo, but, whatever.

Signed-off-by: Anders Kaseorg <anders@zulip.com>

web/src/sent_messages.ts

@@ -98,7 +98,7 @@ export function start_tracking_message(opts: {local_id: string; locally_echoed:
     }
 
     if (messages.has(local_id)) {
-        blueslip.error("We are re-using a local_id");
+        blueslip.error("We are reusing a local_id");
         return;
     }
 

web/tests/unread.test.cjs

@@ -178,7 +178,7 @@ test("changing_topics", () => {
     // Test defensive code.  Trying to update a message we don't know
     // about should be a no-op.
     event = {
-        topic: "brunch",
+        topic: "supper",
     };
     unread.update_unread_topics(other_message, event);
 

zerver/actions/message_send.py

@@ -1456,7 +1456,7 @@ def send_rate_limited_pm_notification_to_bot_owner(
         return
 
     # We warn the user once every 5 minutes to avoid a flood of
-    # direct messages on a misconfigured integration, re-using the
+    # direct messages on a misconfigured integration, reusing the
     # UserProfile.last_reminder field, which is not used for bots.
     last_reminder = sender.last_reminder
     waitperiod = timedelta(minutes=UserProfile.BOT_OWNER_STREAM_ALERT_WAITPERIOD)

zerver/lib/stream_color.py

@@ -48,7 +48,7 @@ def pick_colors(
         if i < len(available_colors):
             color = available_colors[i]
         else:
-            # We have to start re-using old colors, and we use recipient_id
+            # We have to start reusing old colors, and we use recipient_id
             # to choose the color.
             color = STREAM_ASSIGNMENT_COLORS[recipient_id % len(STREAM_ASSIGNMENT_COLORS)]
         result[recipient_id] = color

zerver/tests/test_subs.py

@@ -208,7 +208,7 @@ class TestMiscStuff(ZulipTestCase):
 
         """
         If we are assigning colors to a user with 24+ streams, we have to start
-        re-using old colors.  Our algorithm basically uses recipient_id % 24, so
+        reusing old colors.  Our algorithm basically uses recipient_id % 24, so
         the following code reflects the worse case scenario that our new
         streams have recipient ids spaced out by exact multiples of 24.  We
         don't try to work around this edge case, since users who really depend