Plainchant Dev Diary: Writing Before Formatting

Plainchant started life in July as a single web page with a rather unwieldy name: the SLASH Frictionless Screenwriter. It had a text box on one side and a formatted screenplay on the other. You typed, and it tried to guess what you meant.

The idea behind it has not changed since. Plenty of writers, many of them neurodivergent, get stuck on screenplay formatting: margins, capital letters, where a character's name goes, what a transition looks like. The app should handle all of that, so the writer can simply write.

This week the prototype became a real project.

A Project With a Memory

Most of the code is written in short working sessions with an AI coding assistant, and each session starts with no memory of the last. So before any features, the project got a way to remember:

• A roadmap, where every piece of work has a permanent ID
• A handoff document, rewritten at the end of every session so it always says where things stand right now
• A decision record, where every choice a future session might question is written down with its reasons

That last one has already paid for itself. Decisions do not get argued twice when the reasons are one search away.

A Parser That Does Not Guess

Scripts are written in Fountain, a plain-text screenplay format. You type INT. KITCHEN - NIGHT and it becomes a scene heading; a name in capitals on its own line becomes a character about to speak.

The prototype guessed a lot. A lowercase "cut to:" became a transition, sometimes. Guessing makes behaviour unpredictable and impossible to test, so the new parser follows the Fountain rules exactly. Where a writer expects some leniency, such as typing a name in lowercase, the editor fixes the text as they type, and the parser stays strict.

The parser is a small, separate module with its own tests. It knows nothing about the page it runs on, which means the same file can be tested on its own and shipped in the app unchanged.

Never Lose Words

One rule outranks almost everything else: a writer's words must not disappear. Reloading the page now brings back the script you were working on. Saving happens as you type, and once more when you switch away from the tab or close it. And clearing the editor by accident does not overwrite the saved script; New is the way to start fresh.

Phones, and Then Tablets

The prototype split the screen in half on every device, which on a phone meant two unusable slivers. Phones now show one pane at a time, the script or the formatted preview, with a menu for everything else.

Tablets turned out to be the most likely device of all, and measuring them found a real bug: anywhere below about 1,100 pixels wide, the preview was being clipped by up to 341 pixels. Screens under 1,024 pixels now get the one-pane layout too, and the screenplay sizes itself to the column it is given rather than to the window.

Helping Hands While Typing

The first typing helpers arrived the same day:

• Tab turns the current line into the next element: a character, a scene heading, a transition
• Enter knows what usually comes next, so after a character's name you are ready to type what they say
• Scene headings and character names become capitals as you type
• On a touch screen, a row of buttons above the keyboard does what Tab does, since tablets and phones rarely have one

Every one of these goes through the browser's own editing commands, so Undo still works exactly as a writer expects.

Where the Project Stands

The first phase of the roadmap is complete: restoring the last script, a proper parser, and saving that keeps up. There are now 94 unit tests and 267 checks that drive the real app in a browser, clicking buttons and typing text the way a person would.

Next: A Front Door

The app works, but a newcomer opening it for the first time would have no idea what to type. It needs a welcome, a proper Help window, and, while we are at it, a name that is not "Frictionless".