From 283e0a03d56a694e6e59ad7ec3c1257943a50872 Mon Sep 17 00:00:00 2001 From: Joel Natividad <1980690+jqnatividad@users.noreply.github.com> Date: Mon, 4 Sep 2023 19:11:52 -0400 Subject: [PATCH 1/3] readme: remove redundant point --- README.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/README.md b/README.md index 51188654d..60189fa28 100644 --- a/README.md +++ b/README.md @@ -233,8 +233,6 @@ 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 generally acceptable for `Regex::new` to get a little slower if it means that From 35bec0d78be88244f0daf4df3ddc744ea7046b50 Mon Sep 17 00:00:00 2001 From: Joel Natividad <1980690+jqnatividad@users.noreply.github.com> Date: Mon, 4 Sep 2023 21:15:19 -0400 Subject: [PATCH 2/3] visually emphasize differences --- README.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 60189fa28..ba678478a 100644 --- a/README.md +++ b/README.md @@ -233,8 +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 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 From b4b529b8230ecf53196c6578a7caf433d499b076 Mon Sep 17 00:00:00 2001 From: Joel Natividad <1980690+jqnatividad@users.noreply.github.com> Date: Mon, 4 Sep 2023 21:29:47 -0400 Subject: [PATCH 3/3] italicize only --- README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index ba678478a..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