adjust --keep-stage-std section

src/building/suggested.md

@@ -329,15 +329,14 @@ A common example is that you need to add a `debug!` statement to inspect the val
 some state or better understand the problem.
 In that case, you don't really need a full build.
 By bypassing bootstrap's cache invalidation, you can often get
-these builds to complete very fast (e.g., around 30 seconds). The only catch is
+these builds to complete faster. The only catch is
 this requires a bit of fudging and may produce compilers that don't work (but
 that is easily detected and fixed).
 
 The sequence of commands you want is as follows:
 
 - Initial build: `./x build library`
 - Subsequent builds: `./x build library --keep-stage-std=1`
-  - Note that we added the `--keep-stage-std=1` flag here
 
 As mentioned, the effect of `--keep-stage-std=1` is that we just _assume_ that the
 old standard library can be re-used.
@@ -348,11 +347,10 @@ the compiler, which controls how the compiler encodes types and other states
 into the `rlib` files, or if you are editing things that wind up in the metadata
 (such as the definition of the MIR).
 
-**The TL;DR is that you might get weird behavior from a compile when using
-`--keep-stage-std=1`** -- for example, strange [ICEs](../appendix/glossary.html#ice)
+That is, you might get weird behavior from a compile when using
+`--keep-stage-std=1`, for example, strange [ICEs](../appendix/glossary.html#ice)
 or other panics.
 In that case, you should simply remove the `--keep-stage-std=1` from the command and rebuild.
-That ought to fix the problem.
 
 You can also use `--keep-stage-std=1` when running tests.
 Something like this: