Question: Nesting dialog

[beamercola]

Is there any reason why dialog_begin and dialog_end couldn't be

{
  type: "dialog",
  lines: [
    { character: "Jen", line: "Nice to meet you" },
    ...
  ]
}

Seems like it'd make parsing a bit easier. I'm using this in React, and needing a way to replace string matches with react components and finding these tokens a little hard to work with.

If it's helpful or wanted I can help code

[jonnygreenwald]

Heya! Apologies for the late response, but I've been thinking on your question while offline.

Version 1.0.0 of this library is a fork of Matt Daly's Fountain.js and originally was just a pet project for me to try out a Typescript conversion. So, to answer your question, that's how Matt designed the token schema, so I preserved it for those who wanted to continue to use his library.

As these things go, it's obviously grown somewhat beyond that original intention and perhaps it's time to modernize. To do this would require a major bump (version 2.0.0).

I'm for it and was considering, if going for a major, to also implement an options object akin to marked.js.

let output = fountain.parse('string', {
    extensions: true,
    tokens: true
});

My thinking here is, it opens the door for additional options, like expanding rendering, or adding helpful additions that may b out of Fountain's intended spec such as parsing extensions like (O.S.) or V.O..

Regarding token structure, I'd like to be thoughtful here and think about how to organize blocks and tokens, perhaps taking some notes from CommonMark on organization, etc.

Here's an initial example:

{
type: 'script',
title: { ... },
tokens: [
...
  { type: 'action', text: 'Jen runs into directly into AMELIA.</br>Coffee goes everywhere.'}
  // a `dual-dialogue` block would hold two dialogue blocks, etc.
  {
    type: 'dialogue',
    name: 'Jen',
    tokens: [
      { type: 'speech', text: 'Nice --',
      { type: 'parenthetical', text: '(through gasps of air)'},
      { type: 'speech', text: 'to meet you...'},
    ]
  }
...
]}

This keeps the structure somewhat similar to how the parser works now, like I'm not putting action or speech into a block like you could, but it creates a more recognizable AST that (hopefully) addresses your question.

I'd like to take a crack at it initially and flesh out the idea, but would love initial input from you or past contributors like @zenibako and @rezonant as well as would like reviews of the PR before push.