Improve the screenplay editor

jbilcke-hf commented 1 month ago

Context

The current screenplay editor isn't very useful, there are some syncing bugs and editing the screenplay (ie. doing changes to it) has no effect.

Also, only screenplays in the "hollywood-style" format are supported, so any text without the correct indentation will fail.

Goal

The goal of this ticket is to implement various changes (we can also create sub-tickets). See the tasks at the end of the ticket.

Limitations / things to checks

Performance issues

Saving a screenplay can be computationally intensive since it has to be converted back to a segment.

Even if we add or remove only one line, this can have a cascade effect (eg. shift everything left or right).

To optimize this, we should not run the whole screenplay through the editor, but instead only the current line, and do a localized update (similar how today resolving a segment can change its length, but the cascade effect is done in an efficient way).

Which format to use in the editor itself?

I think we can keep the idea of having only one format inside the screenplay editor (and use import/export functions to convert it to other formats). This format can be Fountain.

For people who want to generate a story from something else (eg. just a sentence, or a synopsis), we can add a little UI workflow to do that (eg. a "create new project" menu entry, and a dialog to show a wizard assistant)

How to implement

Get familiar with Fountain: https://fountain.io/developers/
Get familiar with Monaco: https://microsoft.github.io/monaco-editor/
start with small, simple features (look at our existing examples in the code)

For the task of taking a sentence and converting it to changes in the timeline's segments, I think we can use a LLM whenever a scene needs to be updated. It will do a better job than if/else heuristics.

Acceptance criteria

[ ] making a change to the screenplay should be reflected in the timeline
[ ] no need for a save button, but we can have an undo/redo button
[ ] the timeline's position correctly sync with the screenplay editor (content + scroll)
[ ] the screenplay editor's position correctly sync with the timeline (content + scroll)
[ ] selecting segments in the timeline should select lines in the editor
[ ] selecting lines in the editor should select segments as well
[ ] show the avatar of characters
[ ] the position of the current playback cursor (in the timeline) should highlight the matching lines in the editor
[ ] allow individual scene collapse (see https://github.com/microsoft/monaco-editor/issues/4024#issuecomment-1864802346)
[ ] allow global scene collapse (you can add buttons)
[ ] pre-process screenplays to Fountain
[ ] add some syntax coloration specific to the Fountain syntax

sendn0des commented 1 month ago

To optimize this, we should not run the whole screenplay through the editor, but instead only the current line, and do a localized update (similar how today resolving a segment can change its length, but the cascade effect is done in an efficient way).

agreed. do you think we need a "Commit" popup to happen upon user changes to script?

my initial idea was that the "writing" section was in another tab. so when a user went back to the timeline, this was considered a "commit". This also served a purpose to allow user to have "writers brain" vs. "editing brain" (while still retaining script on the edit view). Just having it noneditable in edit view.

edit: @lalalune : actually nm - just looking at your inlines on the pr you made. mouse blur is interesting. i had thought of tabs (as above) but i think a clever "commit" or "save to" can work.

down the road probably want to have the word processing go fullscreen for people who are going to make more sweeping changes before previewing again

jbilcke-hf commented 1 month ago

maybe not a pop-up, I think yes the unblur is a good compromise, as it represents a user context switch (they're "done" with editing when they unfocus)

although I would love to be able to have real-time updates one day (ie. for each key press, with a bit of a debounce/throttling)

it's just that right now (and for purely technical reasons which could be optimized one day), we need to make it a special operation that happens only every so often

sendn0des commented 1 month ago

although I would love to be able to have real-time updates one day (ie. for each key press, with a bit of a debounce/throttling)

totally. imo it's the ultimate.

ill think more on this and think of user function. the unblur could be VERY interesting (and almost gamelike). it's nothing i've ever really seen before

jbilcke-hf / clapper