Simplify rendering.

I realized I can set colors on in trycmd: I don't mind the output being a bit
garbled, the point is to check if things have changed. By doing this, I don't
need to render things again, and that also means that the line numbers for the
inclusion can actually match the numbers in the file, which is SO NICE.

Author: steveklabnik

.github/workflows/deploy.yml

@@ -22,17 +22,16 @@ jobs:
           mkdir mdbook
           curl -sSL $url | tar -xz --directory=./mdbook
           echo `pwd`/mdbook >> $GITHUB_PATH
-      - uses: baptiste0928/cargo-install@v3
-        with:
-          crate: jj-cli
-          version: "=0.27.0"
+      - name: Build jj
+        run: |
+          cargo build
       - name: Configure jj
         run: |
-          jj config set --user user.name "Steve Klabnik"
-          jj config set --user user.email "steve@steveklabnik.com"
+          cargo run --bin jj -- config set --user user.name "Steve Klabnik"
+          cargo run --bin jj -- config set --user user.email "steve@steveklabnik.com"
       - name: Build Book
         run: |
-          cargo build && PATH=$PATH:target/debug/ mdbook build book
+          PATH=$PATH:target/debug/ mdbook build book
       - name: Setup Pages
         uses: actions/configure-pages@v5
       - name: Upload artifact

.vscode/settings.json

@@ -1,9 +1,25 @@
 {
     "cSpell.words": [
+        "abbb",
         "DVCS",
         "hljs",
         "kozrnusy",
+        "mdiff",
+        "mfde",
+        "mfed",
+        "mgit",
+        "mgoodbye",
+        "mindex",
+        "mmznvnuw",
+        "mnmounps",
+        "mpqvmvrn",
+        "mquwwlss",
+        "msrc",
+        "mtrqnyzv",
+        "mtrunk",
         "mtuyzlkn",
+        "mvnlxpxw",
+        "mzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz",
         "nmounps",
         "noreport",
         "nvnlxpxw",

book/src/core-concepts/changes-commits-and-revisions.md

@@ -80,7 +80,7 @@ one, it will refuse unless you pass `--ignore-immutable` as an argument.
 
 Let's look at `jj log`:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:63:70}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:68:75}} 
 
 We have the green `@`, but its parent instead has a `○`. This change
 is mutable. But what about `p`? It has a `◆`. This change is immutable.
@@ -103,7 +103,7 @@ to us right now.
 We can use `jj show` to show information about changes. The root change
 has a change ID of all `z`s, let's check it out:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:73:81}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:78:84}} 
 
 Pretty fun. Wait, what's that `Commit ID` doing there? Okay, let's
 talk about commits.
@@ -117,7 +117,7 @@ So we've been talking about how changes are different than `git`'s commits...
 but `jj` also has commits. Let me explain. Let's use `jj st` to look at our
 current change:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:83:87}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:88:91}} 
 
 Do you see how we have four identifiers there?
 
@@ -134,7 +134,7 @@ the contents of the commit, when you create a new git commit, you're also going
 to get a different ID. Here, let's give it a try: modify `src/main.rs`, in any
 way that you'd like. Then we'll run `jj st` again:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:92:97}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:99:103}} 
 
 `o` used to have a commit ID of `95d5c471`, but now it's `c920ae70`. Our change
 ID remains stable, but the commit ID will change over time.
@@ -143,7 +143,7 @@ This is very powerful! Part 4 of the tutorial is titled "Fixing Problems," and
 a lot of the stuff we will talk about there is powered by commits. We can
 use `jj evolog`, the "evolution log," to see how a change has evolved over time:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:99:106}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:106:111}} 
 
 There are a lot of flags to control `jj evolog`'s output. I've chosen the
 `summary` flag here to show which files we changed.

book/src/core-concepts/throwing-away-changes-and-jj-undo.md

@@ -7,7 +7,7 @@ Getting rid of changes is very easy in `jj`: we can do it with `jj abandon`.
 
 If you remember, we're in the middle of some stuff:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:107:112}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:114:118}} 
 
 If you are coming to this section fresh, just type `jj new` a few times to
 give yourself some good changes. Done? Great. Let's throw them away.
@@ -17,25 +17,25 @@ give yourself some good changes. Done? Great. Let's throw them away.
 Let's say we don't like that "hello and goodbye world" stuff. We're not going
 to pursue that further. Getting rid of it is as easy as:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:114:118}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:128:132}} 
 
 By default, `jj restore` takes changes from your parent change, and puts them
 into `@`. But there's `--from` and even `--into` flags you can pass as well.
 Let's grab the diff from our first commit, and apply it to `@`:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:121:125}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:128:132}} 
 
 As you can see we aren't empty any more. Well, what does our code look like?
 Let's use `jj diff` to see:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:128:132}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:135:139}} 
 
 This format is different than `git`'s: we have red and green to indicate
 what's changed, for example.
 
 If you want to get a `git` style diff instead, that is easy as well:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:135:144}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:142:151}} 
 
 We only had one file that was changed, so we didn't *need* to pass the path to
 `jj restore`, but `jj restore` is mostly used with individual paths.  If we
@@ -50,7 +50,7 @@ But what if we want to delete a change entirely?
 At any time, you can get rid of a change with `jj abandon`. It's tons of fun!
 Let's try it:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:147:151}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:154:158}} 
 
 This throws away our current change. We abandoned `opqvmvrn`, and since that
 was the same as `@`, `jj` makes a new change for us, in this case, called
@@ -59,11 +59,11 @@ was the same as `@`, `jj` makes a new change for us, in this case, called
 But what if we abandon something that's not `@`? Like, let's say, `t`, the
 change that we're currently on top of. What's the worst that could happen?
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:154:160}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:161:167}} 
 
 So what happened here?
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:163:169}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:170:175}} 
 
 As you can see, because we got rid of the commit we were standing on, instead of throwing
 us away too, `jj` just re-parented us onto the abandoned commit's parent. We're still on
@@ -78,11 +78,11 @@ I have good news.
 
 There's a really useful subcommand that goes by `jj undo`:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:171:175}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:178:182}} 
 
 That's it! We're good again:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:178:185}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:185:192}} 
 
 Everything is back to where we put it. We can always `jj undo` to undo
 *any* of our last operations, and `jj` will make things right again.
@@ -95,7 +95,7 @@ though. What do you think would happen if we `jj undo`'d again right now?
 
 Make your guess, and then give it a try:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:188:195}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:195:201}} 
 
 That's right: the last thing you did was an `undo`, so an `undo` just
 `undo`es that `undo`. Hilarious, but kind of frustrating. There's a
@@ -105,7 +105,7 @@ a bit trickier than it sounds.
 Regardless, we can fix this: there's no problem with `jj undo` that you
 can't solve by throwing more `jj undo`s at it:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:197:203}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:204:210}} 
 
 Whew. That's enough of that.
 
@@ -114,24 +114,24 @@ Whew. That's enough of that.
 Having an empty change with no description is fine to have if it's
 `@`, or if it has children. Here's a fun party trick:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:206:210}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:213:217}} 
 
 That's right: `jj new` can take `--before` or `--after` flags to
 squish a change in between others. (Yes, we're trying to make squish happen.)
 And `--no-edit` means that we don't want to move our working copy
 to the new change: `@` stays right where it is:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:213:222}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:220:229}} 
 
 So that change is fine. But what if we move away from these changes?
 Let's make a new change on top of `trunk`:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:225:228}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:232:235}} 
 
 We had two empty commits on top of `goodbye-world` before, but
 what about now?
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:230:239}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:238:247}} 
 
 Our empty change `nvnlxpxw` was discarded, automatically. You don't have to
 worry about `jj new` littering up your repository, empty changes will end up

book/src/getting-started/cloning-a-repository.md

@@ -12,7 +12,7 @@ of your own.
 Next, let's clone down our fork. Go to the directory where you'd like to create
 your clone, in my case, that's `~/src`. And then type this:
 
-```bash
+```nohighlight
 $ jj git clone --colocate git@github.com:<YOUR USERNAME>/hello-world
 Fetching into new repo in "/home/<YOUR USERNAME>/src/hello-world"
 bookmark: trunk@origin [new] untracked
@@ -30,7 +30,7 @@ command, `--colocate`. `jj` supports two different kinds of repositories:
 colocated, and non-colocated. What's the difference? Well, let's take a look
 at our repository:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:12:19}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:15:22}} 
 
 We have both a `.jj` and a `.git` directory at the top level. This means both
 jj's information as git's information are co-located: they're next to each
@@ -44,7 +44,7 @@ at the root of the repository will still work.
 
 Let's see what our repository's history looks like:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:22:27}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:26:31}} 
 
 This looks a bit different than `git log`, but it's the same general idea: we
 can see where we our in our history.

book/src/getting-started/interacting-with-github.md

@@ -8,7 +8,7 @@ would make it harder to understand.
 
 Let's look at that `jj log` output again:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:49:56}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:54:61}} 
 
 Do you see that little `trunk` over on the right there? That is a *bookmark*
 in `jj`, and it's how `jj` understands git branches. `trunk` is the name of
@@ -24,7 +24,7 @@ locally, but when we interact with GitHub, it needs a branch name.
 
 To create a bookmark, we can use `jj bookmark`:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:59:61}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:64:65}} 
 
 `jj bookmark create` takes a name for the bookmark, and then we also pass a `-r` flag.
 This is short for "revision," which is a sort of catch-all name for the various kinds
@@ -33,7 +33,7 @@ the change ID. In this case, we pass `@-`, which means "the parent of `@`."
 
 Let's look at our log:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:63:70}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:68:75}} 
 
 We can now see `goodbye-world` listed on the right. Great! Let's push that up
 to GitHub. But before we do, a warning:

book/src/getting-started/making-a-new-change.md

@@ -7,7 +7,7 @@ simplest possible workflow. If you're a fan of building up small commits via the
 If you remember from the end of the last section, we're on an empty change.
 You can double check with `jj status` (or `jj st`):
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:29:32}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:34:37}} 
 
 So what is a change, anyway? It is the core primitive you'll be working with in
 `jj`. We'll talk about that actually means in Part 2. For now, you can think of
@@ -35,7 +35,7 @@ fn main() {
 
 A bit fatalistic, but it works. Let's run `jj st` again:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:37:42}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:42:46}} 
 
 We can see we've modified `src/main.rs`. Whenever we run a `jj` command, `jj`
 will snapshot all of the changes that we've made to any files in our repository
@@ -51,14 +51,14 @@ but now I love it.
 Let's say we're happy with the contents of this change. We're done, and we want
 to start working on something else. To do that, we can use `jj commit`:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:44:46}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:49:51}} 
 
 Easy enough! Our working copy is now on a fresh new change, and its parent
 is our "Goodbye, world!" change that we just committed.
 
 To see our changes in context, let's look at `jj log` again:
 
-{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:49:56}} 
+{{#trycmdinclude tests/tests/cmd/getting-started.trycmd:54:61}} 
 
 You can see that we're currently working on an empty change. It has `x` as a
 change ID, but there's also a little `@` there: `@` is an alias for the working