Fix typos in Buglet Bindings post

diff --git a/source/posts/2024-07-15-on-buglet-bindings.org b/source/posts/2024-07-15-on-buglet-bindings.org
index 06cdf26a06f36653fc9dda34ffc222c462a7c8ab..25174166fcee8ede3e50de0bbab719288a6e104c 100644 (file)
--- a/source/posts/2024-07-15-on-buglet-bindings.org
+++ b/source/posts/2024-07-15-on-buglet-bindings.org
@@ -20,13 +20,13 @@ In short, say you're using ~completing-read~:
 #+end_src
 
 So far so good, but when you try it out you realize that completion is
-case-sensitive by default, so type =s TAB= doesn't complete to =Spam=
-and you have to type =S TAB= with an uppercase =S= instead.  That's a
-nuance, so you venture to make completion case-insensitive.  You could
-just configure you're Emacs with ~completion-ignore-case~ set to ~t~,
-but that affects all kinds of completion, and you only want "this"
-completion to be case-insensitive.  That's when you fall head first
-into the /buglet-binding/ pitfall, and do this:
+case-sensitive by default, so typing =s TAB= doesn't complete to
+=Spam= and you have to type =S TAB= with an uppercase =S= instead.
+That's a nuance, so you venture to make completion case-insensitive.
+You could just configure you're Emacs with ~completion-ignore-case~
+set to ~t~, but that affects all kinds of completion, and you only
+want "this" completion to be case-insensitive.  That's when you fall
+head first into the /buglet-binding/ pitfall, and do this:
 
 #+begin_src emacs-lisp
   ;; BAD!
@@ -67,9 +67,9 @@ bindings.  For example:
     (completing-read "Frobnicate: " '("Foo" "Bar" "Spam")))
 #+end_src
 
-[ Actually, since Emacs version 29, ~completion-ignore-case~ in
-  particular gets a special treatment that requires some additional
-  work to handle correctly.  This is fine for other variables.  ]
+/Actually, since Emacs version 29, ~completion-ignore-case~ in
+particular gets a special treatment that requires some additional work
+to handle correctly.  This is fine for other variables./
   
 While let-bindings are local to a certain piece of code, that piece
 may become boundless when recursive edits or other forms of arbitrary
@@ -82,24 +82,24 @@ A /bug-let/, or a /buglet-binding/, is a coding error in which a
 let-binding has unintended influences on some code in the scope of
 that let-binding, like in the example we saw earlier.  Let-binding
 special variables (those defined with ~defvar~, ~defcustom~, etc.)
-around functions that read input in the minibuffer can often yield
-buglet-bindings.  Variables that are often buglet-bound include
+around functions that read input in the minibuffer often brings about
+such bug-lets.  Variables that are often buglet-bound include
 ~enable-recursive-minibuffers~, ~completion-extra-properties~,
 ~completion-ignore-case~, ~minibuffer-allow-text-properties~,
-~completion-ignored-extensions~ and ~minibuffer-completing-file-name~.
-But it's not all minibuffers, buglet-bindings are a more general class
-of bugs that can occur even when no minibuffers are in play.  When you
-let-bind special variables, you need to ensure that everything in the
-binding's scope cooperates with it correctly.  That's easy to do for
-your own special variables that only your code uses: if all other code
-is indifferent to the value of your variable, then all you need to
-check is that your code is not called recursively, or that it's
-prepared for being called recursively with the let-binding in effect.
-For special variables defined elsewhere, keep the scope of
-let-bindings as small as possible and check that all functions in
-scope are known and that the let-binding doesn't change their behavior
-in unindented ways.  If you're invoking a user-supplied function in
-the let-binding scope, document that clearly so users can prepare
-their code accordingly.
+~completion-ignored-extensions~, and ~minibuffer-completing-file-name~
+among others.  But it's not all minibuffers, buglet-bindings are a
+more general class of bugs that can occur even when no minibuffers are
+in play.  When you let-bind special variables, you need to ensure that
+everything in the binding's scope cooperates with it correctly.
+That's easy to do for your own special variables that only your code
+uses: if all other code is indifferent to the value of your variable,
+then all you need to check is that your code is not called
+recursively, or that it's prepared for being called recursively with
+the let-binding in effect.  For special variables defined elsewhere,
+keep the scope of let-bindings as small as possible and check that all
+functions in scope are known and that the let-binding doesn't change
+their behavior in unindented ways.  If you're invoking a user-supplied
+function in the let-binding scope, document that clearly so users can
+prepare their code accordingly.
 
 Other than that, let-bind away, and stay safe!