Coding 2024-02-11
Okay, writing this early in case my laptop has another little accident like it did about half an hour ago. I've currently shifted gears to considering how I might convert my disorganized draft file into a more comprehensible outline file.
Here is the hierarchy as I see it at a glance:
- Top-level: title
- Second-level: preface; the preface contains explanatory notes about the word choices in the book(s); it therefore is needed to understand/contextualize the story proper, but it does not fit into the structure of the rest of the outline; spell-checking it will require a different dictionary from the rest of the book; there are some parts of the "preface" that are more properly "notes", and should be transcribed into a separate branch of the .leo file's tree structure.
- Second-level: main story; the actual contents here are a muddle of notes-to-self, outline fragments, actual text meant to show up in the draft, and who knows what else; of interest from the notes is that I call out how a specific event should be followed by a chapter break.
- Lower-level: chapters; not currently planned out except in the broadest contours; I'm aware that whether to have chapters is a choice, but the choice of chapter break I have in there is really amusing to me, so it's a choice I'm making in the affirmative; I'll reconsider if I end up with "Chapter 2: Everything Else"; the other thing I need to ponder some is the question of chapter titles, subtitles, quotations, etc.
- Lower-level: "scenes" and "summary"; Rather than my draft, this is based on the writing advice I've been reading; The idea here is that I would like to reason about smaller parts of the narrative than a single chapter, so I should call them out here.
- Other levels: I am aware that I could come up with groupings of chapters (I probably will end up needing "book" to be honest, because the draft ends on a sequel hook), but I don't want to get ahead of myself; similarly, maybe there are divisions that I'd like between chapter and scene, or within scene, but my gut feeling is that I should try working with book-chapter-scene, and see what that gets me; (the obvious things that occur to me are "paragraph" and "sentence", which I hope illustrate why I think it may be best to hold off on dividing things up that finely).
If we assume that I'm going with book-chapter-scene, then I've got some ideas for what I need to get things right.
- Books must have a title, and this title must end up in the generated documents.
- Chapters may have a title etc, which should end up in the generated documents.
- I would like chapters to be consistent about what such information they have associated with them.
- Chapters are also numbered.
- It is likely but not certain that I would like to associate different kinds of metadata with scenes, such as which arcs they relate to.
- Some of this metadata is best expressed through references to scenes in other parts of the tree.
Summing things up:
- Every division between book and chapter, inclusive, represents a visible distinction in the final output, including, for example, specific formatting to call out the boundary.
- These nodes are to be named with a word or abbreviation indicating their role (for verification purposes), and a short summary of their contents, for aid in navigating the tree.
- The contents of these nodes are to consist of some lines of metadata, followed by a more detailed summary of the child nodes.
- The contents of a node should be fully accounted for by its direct children.
- For evaluating the outline, I would like the ability to mark specific nodes as "included literally" or something; such nodes should not be allowed to have child nodes.
I wish to process all of this into a few different forms:
- preface only
- story without preface
- story with preface (which is then processed into other forms)
- absolutely everything (not sure the exact way this should present everything, so I'd like to hold off for now)
To accomplish this, I'm pretty sure I need:
- Use of node tags for repeated scalar or mostly-scalar metadata.
- Use of inline metadata for key-value metadata, unless there is some alternative.
I think this is all solid as an idea, but I need to take some time to sketch it out on paper for a bit before I can implement it. And none of that is happening now, because it's late again.
Good night.