It would great to be able to use the $include tag to insert a folder, a file or a hierarchy of folders and files in one Scrivener project to another for the purposes of compiling text from one project into the body of another.
Another option that might be more elegant would be something that supported ‘live inclusion’, where folders and documents in one project could appear virtually in the binder of another project.
This would help in producing interrelated documents that share common elements.
In the more virtual model, one could imagine two-way appearances of content, so when one project is opened and an update made to a folder or document, those folders or documents would update into those folders/documents appearing in other projects, and vice versa, depending on the starting point for the change. Compilations would always pick up the most current content, whatever its point of origination.
I’ve been thinking about various workarounds to achieve this objective by other means, but a straightforward application feature set that worked elegantly from within Scrivener projects would be a great addition. Versioning policy documents based on pieces of text that need to be continuously maintained and updated is a signficant part of our editorial work.
You have probably already encountered the intended approach for this type of problem, which is described in this older thread: for stuff multiple projects need to have the same content for, one uses files on the disk for inclusion, rather than binder items.
What you are proposing would be theoretically awesome—but a bit of a nightmare in terms of implementation (and I’m just speaking of the <$include:...> tag here in that, actually mirroring content from multiple potentially simultaneously open projects would be more than just a bit of a nightmare given the architecture of the software).
Yes, I’m pretty familiar with the substance of what’s discussed with that old thread.
I’m onto considering options using RTF file synchronization.
Another route you might go with new development would be a more sophisticated file synchronization manager.
The way file synchronization works now, showing what’s changed when a project is opened or synced, is pretty handy for keeping track of recent changes.
If multiple projects could make use of RTF file resources in common through synchronization in and out of projects (including intermediary use of the files, say with Word, that might be an even better approach. If I were to hazard a guess, to get from where you are now to where you’d need to be, something would have to change with how the RTF files are named (preceded with a universal identifier instead of a binder order number?) and a given project would need to store the association between the document identifier and its own binder order. But the problem with that might be the loss of organization of the files in the [Finder] folder being synced for someone just using a word processor to author and edit.
My sense is that the Finder folder should just have its own structure, and the sync manager inside a given Scrivener project could just make it possible to specify a list of Finder folders and/or individual nested documents to sync. To make this all work you might need to introduce a new, specialized folder to the binder that can only be used for titling but not holding text. Scrivener folders (really documents, since they can hold text) would just carry on using file naming conventions to distinguish them from Scrivener text documents.
More sophisticated synchronization management might help you sidestep what you foresee using simple compile inclusion. So that could be another way to go.
But the objective here is shareable text objects, where the file organization in a shared folder or in associated projects can be unique in each case, and where the synchronization setups are as granular as the user might need.