View on GitHub

scriv-git-pages

Writing in Scrivener for GitHub Pages

Post-Processing Built In Top TL; DR

Assessing Where We Are

Everything seems to be working. That means it’s a good moment to look at what we have, in this booklet, and in our Scrivener setup. It’s a good moment to decide whether we’re done for now, what we wish we had done, and what we might want to do right now.

Leonardo supposedly said “Art is never finished, only abandoned”. Probably he said it in Italian, I suppose. Anyway, it’s the same with a program, a set of web pages, or a Scrivener setup. Sometimes we stop, but it’s never really finished. And right now, I’m pretty sure there’s more to do.

Summary TL;DR

Of all the things we might do, this seems most valuable to me. Let’s put a “Too Long; Didn’t Read” summary in the booklet, summing up all the settings and changes I’ve made, without so much intervening narrative. That seems to me to be a decent service for people who just want to git ‘er done rather than read a story.

That won’t be much fun, but it’ll probably be worth doing.

Booklet Organization

My Scrivener binder is organized into only two levels, section, and sub-section. The sections get headings, and the subs do not. I can sense a larger level of organization trying to come into being here. Something like section, chapter (or web page really), and sub-page.

It might be worth making that change for this booklet.

Synopses

Scrivener’s index cards have a title, which is the same as the title in the binder, and a synopsis, the text written on the card. I have a vague idea that I’d like to use the synopsis as a leading quote on the pages, because in something I wrote, ages ago, I put something like that at the heading of each chapter.

Of course I could just type them in. And there is a Scrivener “placeholder” that will pull the Synopsis in wherever you want it. I’ll put this card’s synopsis here:

In this section, we look at where we’ve been, and where we might want to go.

Commonly in writing something like this booklet, you want to refer to some other part of the text. On the internet, of course, we’d want a link to the actual page and paragraph. Scrivener does support this kind of thing, and they’ll act as links in a single web page or PDF (I believe). Clearly they wouldn’t work once we split up the file, because Scrivener doesn’t know we’re going to do that.

We might want to figure out a way to support those links. If we do, the most interesting bit will be finding the right reference in Scrivener’s big dump of references, and converting it to work with our structure. I think this would turn out to be challenging. One could do a lot of links by hand before paying for this feature, but it’s tempting to at least look into it.

Other Embeddings

There might be other kinds of embeddings we’d want to do. If we do go to a three-level structure, we might want to put a table of contents for each section at the top of that section. To do that, we’d put a marker wherever the little ToC would go, and we’d need to scan each chunk to see if it needed something embedded in it.

It’s “easy to see” that the same approach we used for the big ToC could be used for any other kind of embedding. They would all have the same structure:

We’d repeat that process until the chunk didn’t split, I suppose. Anyway it seems straightforward.

My style of programming discipline says to build that when I need it, not to build it on speculation. Embedded links might be the opportunity, if I choose to do it.

Conclusion - for now

It seems clear to me that the TL;DR chapter is worth doing. Maybe I’ll start that today, maybe tomorrow. Maybe never: no promises. Stay tuned!

Post-Processing Built In Top TL; DR