You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Every other Fountain editor that supports starred revisions does so by switching the container format to some arbitrary binary or zipping the text file alongside some other blobs of diff data.
Meander won't ever do that. No binaries, only plain text. The zip is somewhat acceptable, but once you've opened the Pandora's box of adding extended syntax... you may as well just continue. Looking at you, John August.
I've experimented with starred revisions to a surprising degree of success by having Meander simply read Git and Mercurial diffs as a switching mode in the parser. I based the target historical versions on tags rather than commits, so that tags could be moved around to provide the writer's preferred historical commit (in case they thought to add something new to the pink revision and now needed to bump it).
As a simplification, the working copy (whatever was on disk at that moment) was always compared to a historical target. You couldn't compare two arbitrary historical points unless you checked the newer one out and compared it to the older.
The issue was that in semi-rare cases, Git would take it upon itself to do it's job very very efficiently, which is storing the diff in the smallest possible form. This meant that some changes were not localised to the site of the writer's actual changes and would result in a big stripe of green or red in the diff — now half the page is starred unnecessarily.
The other issue with this is that asking the average non-technical writer to interface with Meander is already a bit of a stretch, let alone asking them to also deal with Git. The hurried writer making amendments in their trailer on a break is hardly going to want to deal with Git's utterly maddening CLI interface to move a tag around.
Instead, it seems like it might be a better idea to provide a tag in syntax that writers can use to mark changed paragraphs. If they want to version their screenplay, they can do so with whatever tools they like externally. As mentioned before, working copy is always the canonical one in this paradigm.
Anyway, here's a pseudo-syntactic example of what this might look like:
DANIEL @pink
(rage consuming him)
_I DRINK YOUR MILKSHAKE!_
The writer can then export the screenplay with the -r pink flag and all items tagged as pink will be marked with stars.
It could also be combined with the page-locking feature, where pages with headers featuring these tags would be considered the only pages in the output: a -r pink build would then create a PDF with only those pages ready for printing.
I want some feedback on this idea before I implement it natively, but it's otherwise a relatively easy addition to the project.
The text was updated successfully, but these errors were encountered:
Every other Fountain editor that supports starred revisions does so by switching the container format to some arbitrary binary or zipping the text file alongside some other blobs of diff data.
Meander won't ever do that. No binaries, only plain text. The zip is somewhat acceptable, but once you've opened the Pandora's box of adding extended syntax... you may as well just continue. Looking at you, John August.
I've experimented with starred revisions to a surprising degree of success by having Meander simply read Git and Mercurial diffs as a switching mode in the parser. I based the target historical versions on tags rather than commits, so that tags could be moved around to provide the writer's preferred historical commit (in case they thought to add something new to the pink revision and now needed to bump it).
As a simplification, the working copy (whatever was on disk at that moment) was always compared to a historical target. You couldn't compare two arbitrary historical points unless you checked the newer one out and compared it to the older.
The issue was that in semi-rare cases, Git would take it upon itself to do it's job very very efficiently, which is storing the diff in the smallest possible form. This meant that some changes were not localised to the site of the writer's actual changes and would result in a big stripe of green or red in the diff — now half the page is starred unnecessarily.
The other issue with this is that asking the average non-technical writer to interface with Meander is already a bit of a stretch, let alone asking them to also deal with Git. The hurried writer making amendments in their trailer on a break is hardly going to want to deal with Git's utterly maddening CLI interface to move a tag around.
Instead, it seems like it might be a better idea to provide a tag in syntax that writers can use to mark changed paragraphs. If they want to version their screenplay, they can do so with whatever tools they like externally. As mentioned before, working copy is always the canonical one in this paradigm.
Anyway, here's a pseudo-syntactic example of what this might look like:
The writer can then export the screenplay with the
-r pink
flag and all items tagged as pink will be marked with stars.It could also be combined with the page-locking feature, where pages with headers featuring these tags would be considered the only pages in the output: a
-r pink
build would then create a PDF with only those pages ready for printing.I want some feedback on this idea before I implement it natively, but it's otherwise a relatively easy addition to the project.
The text was updated successfully, but these errors were encountered: