From 061ee815ef2c44101dba7b0b124600fcb03c1912 Mon Sep 17 00:00:00 2001
From: Joel Natividad <1980690+jqnatividad@users.noreply.github.com>
Date: Thu, 7 Sep 2023 10:02:09 -0400
Subject: [PATCH] readme: visually emphasize performance criteria difference

There was only a slight wording difference between these two
points, and it was easy to gloss over. So we emphasize that
wording difference to make it a bit easier to notice.

PR #1082
---
 README.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/README.md b/README.md
index 51188654d..7454c166d 100644
--- a/README.md
+++ b/README.md
@@ -233,10 +233,10 @@ nebulous. While nebulous, it guides this crate's architecture and the sorts of
 the trade offs it makes. For example, here are some general architectural
 statements that follow as a result of the goal to be "fast":
 
-* When given the choice between faster regex searches and faster Rust compile
-times, this crate will generally choose faster regex searches.
-* When given the choice between faster regex searches and faster regex compile
-times, this crate will generally choose faster regex searches. That is, it is
+* When given the choice between faster regex searches and faster _Rust compile
+times_, this crate will generally choose faster regex searches.
+* When given the choice between faster regex searches and faster _regex compile
+times_, this crate will generally choose faster regex searches. That is, it is
 generally acceptable for `Regex::new` to get a little slower if it means that
 searches get faster. (This is a somewhat delicate balance to strike, because
 the speed of `Regex::new` needs to remain somewhat reasonable. But this is why