Sync granularity based on type or hierarchy?

Scrivener Scrivener for macOS
1

I live in MultiMarkdown, so I’ve found it very useful to use Scrivener to take everything from notes, scribbles, and outlines all the way through to semantic, MMD-based documents when compiled. So great.

So, I’m also using Scrivener’s wonderful ability to infer <Hn>-level sections based on a [document | group | folder]'s relative location in the Binder’s hierarchy–alongside those wonderful tweaks in the Compile options. Again, the best.

My questions is, based on this use case and the existing features, is there a way to tell Scrivener 2 which [documents | groups | folders] should NOT be treated as separate exportable documents when synced? Viz. which children should always stay inside their immediate parent?

e.g., if I have…

* Top Level Folder 1
    * 2ndary Group
       * Doc 1
       * Doc 2
       * Doc 3
* Top Level Folder 1
* ...

… could I, for example, tell Scrivener that “Doc n”-level documents should not be exported as separate files? Can I use either hierarchy or file type (or even Label or Status) to define which [documents | groups | folders] should or shouldn’t be separately exported parents or children?

Use Case:

If I were a tidier writer, I’d never have one-line-notes, short scribbles, rough drafts, sections, and finished chapters (with which might contain many subsections) living together in the same sacred Drafts folder. But, alas.

And the thing is, Scrivener’s endless fungibility kinda encourages this sort of messy “this just kinda goes here for now” approach. It’s definitely why I love it.

Tricky part is, I’d prefer to avoid resorting to static “##” and “###” type headings in anything but completely final Scrivener drafts (it really limits the flexibility). But I’m also not crazy about subjecting myself to a Simplenote or Elements folder where, say, “three chapters comprised of fifty total sections” is dumped out as “fifty-three separate text files.” Really tough on both reading and writing outside Scrivener.

Can Keith or a sympathetic ninja parachute in to suggest anything from an official method to total hack that might accomplish this or similar? Am I best off to bite the bullet and hardcode via “##”-type headings?

Thanks, all. You’re doing $preferredDeity's work here. Much appreciated.

2

Hi Merlin!

Unfortunately, I’m afraid there’s no way of having several files contained inside one text document when syncing to Simplenote or with the external folder sync - they have to be synced as separate files no matter what. The trouble is mainly a technical one, in that Scrivener relies on a one-to-one mapping between files synced and files in the binder. It would be a lot more complicated and difficult for Scrivener to re-sync with files if some of them contained multiple documents and others didn’t. With folder sync, for instance, it uses the file name to get the title and internal ID - so that needs to be one file for one document in the binder. But it would also get a lot more complicated to parse Simplenote files and map them across to binder documents if several files could be contained in a single Simplenote document. Things could go horribly awry if there was a typo somewhere, for instance.

This might be a possible refinement for the future, but it would take a lot of thought and a different syncing system to achieve it really.

Sorry! I know that’s not what you wanted to hear.

All the best,
Keith

3

Thanks, K. You’re being kind–I know this is a picky edge case.

Thanks also for the wonderful app. I owe you an email, and do wanna make good on my offer to help spread the word. Love the app so.

4

It certainly does make the problem easier when using MMD, though. If the sync engine spliced sections into hash-marked headers, an automated merge-then-split workflow would not be too crazy. Something like this:

Top Level Folder 1 (SomeProject [8])
--

# Top Level Folder 1 [id-8] #

## 2ndary Group [id-23] ##

Blah blah.

### Doc 1 [id-25] ###

More blah blah

The bracket in the title is MMD syntax for a custom ID, and would thus not be a violation of the syntax, meaning this file that Scrivener exported would make a valid MMD file. Meanwhile you’ve got the ID numbers buried in the document for retrieval and insertion after splitting the incoming file during sync.

As for a reasonable interface for defining groups of files for export, that’s more tricky. Level based makes a certain sense, so would label based. “Group all children of documents labelled:” [Chapter], or whatever. A choice between either of those would probably suit a wide crowd between those who are more chaotic and those who have very predictable outline structures.

5

Thanks, Merlin, much appreciated as always!

Ioa - the trouble is that it would have to work not just for MMD, but for all cases. There’s also the problem that as soon as you start putting hash markers in there for MMD, some users will wonder why they don’t affect the structure on re-import, and so on. Definitely one for future thought. Before coming up the the current folder and Simplenote sync, sometime last year I spent ages on another idea whereby you would be able to export documents combined for editing in another application, then have them split up again and synced in Scrivener - much like this. It was hell-ish, though, because as soon as you start temporarily merging files there are all sorts of other considerations you have to take into account (for instance, new documents created within the document, a greater reliance on the user not editing the ID numbers, the fact that order becomes more important and so there is a great expectation of it being maintained on re-sync, and numerous horrible technical details).

So, it’s definitely an idea I like, but one for future thought, I think. Let’s revisit it around 2.2 or 2.3. :slight_smile:

Thanks and all the best,
Keith

6

I’d just like (unhelpfully) draw attention to Mr Mann’s fine title: Sync granularity based on type or hierarchy.
Of course, he does live inside of Multimarkdown, so it’s not so surprising I suppose.

Declan