External Folder Sync splits single inline annotations containing one or more complete paragraphs into many inline annotations, two for each paragraph. This can happen without any external editor ever touching the text.
Method to Reproduce:
In Scrivener->Preferences, Sharing pane, Sync tab: Tick the box beside “Convert text inside (()) and {{}} to inline notes when syncing plain text”.
Create a fresh copy of the Tutorial project and open it.
Use the File->Sync->with External Folder… menu item.
In the “Sync with External Folder” dialog, set up syncing with an external folder of your choice.
In the same dialog, tick “Take snapshots of affected documents before updating”. “Sync the contents of the Draft folder”, and “Sync all other text documents in the project”
In the same dialog, choose Plain Text as the format for both external Draft files and for other external files.
In the same dialog, untick “Automatically convert plain text paragraph spacing” (as one must if using the “Convert Multimarkdown to Rich Text in text and notes” compile option.)
Click the “Sync” button.
Select three contiguous paragraphs in the body of “START HERE”.and make them an inline annotation.
Choose File->Sync->with External Folder Now twice in quick succession.
Expected result:
The inline annotation is unchanged.
Actual result:
The inline annotation is split into 6 annotations, one for each paragraph and one for each paragraph break.
Alternate method to reproduce:
Follow Steps 1–9 above.
Use any plain text editor to open the file “START HERE” in the Notes folder inside the folder created in Step 4 above.
Make a minor change to any paragraph outside the inline annotation.
Save “START HERE” and close the text editor.
In Scrivener, choose File->Sync->with External Folder Now
Result:
Same as above; the single inline annotation is split into 6.
This is much more than merely annoying (though it is annoying.) If the interior of the annotation is written in Multimarkdown, it will no longer display correctly in a Markdown editor, nor compile correctly if annotations are not deleted from the compiled output. If it’s important that the paragraphs be in one annotation (e.g., an editorial comment that will later be converted back to an Inspector comment, or a multi-paragraph footnote) they must be reassembled into a single annotation. Repeated reassembly is not only laborious, but results in many unneeded snapshots, inflating project size and slowing backup.
Thanks for the detailed report! I can confirm this problem easily enough. It looks like it may be an intentional process that is overreaching. The only way for inline annotations to be adjacent like that is if their colours are different, and if you examine the RGB values in the RTF file, you’ll find each segment is seemingly intentionaly colour shifted to protect it from merging with the notes around it.
The sync code would need to protect adjacent notes you make (though it wouldn’t be able to restore the original colour info), so it makes sense it would have code to do that. It just shouldn’t be doing it whenever encountering a newline.
Then again, that part doesn’t seem to be working either. So newlines are carefully separated apart but actual adjacent inline annotations get merged. Two bugs for the price of one, it seems.
I can hardly believe this hasn’t been reported before. And yet… so many things in MMD are terminated by a newline; at first encounter this seems like just one more. It’s yet another frustration in the MMD->Rich Text workflow, which has plenty . I started thinking that Scrivener inline annotations aren’t MMD (there is MMD comment syntax which isn’t being used) and that got me wondering if this wasn’t a bug.
I suppose I might have caught this in 2017 if I’d signed up as a Mac Scrivener beta tester. I won’t let such an opportunity get past me again.
There are two sides to this: First, encoding existing annotations from Scrivener into the double paren syntax in the external file, and second, decoding the double parens back into Scrivener inline annotations.
As far as I can tell, the first side goes swimmingly. Multi-paragraph annotations, and even adjacent annotations, show up in the external plain text files wrapped in double parens exactly as expected.
The problem lies in the decoding routine. It’s not correctly decoding the double parens syntax and creating annotations accordingly. I hadn’t tried adjacent annotations, but as you say, they’re merged.
… I wonder if your thought about deliberately changing colour to separate decoded annotations is correct. I actually doubt this is being done. If I create a new annotation in the external text file, it always comes back the same shade of bright red. I suspect that the decoding routine incorrectly insists that any of the end of paragraph, start of new paragraph, or set of open/closed parens within a paragraph represent annotation boundaries. It’s treating each separated newline character as a new annotation created in the external editor.
The horrid bug that caused the annotations to be split at paragraph breaks even if no Markdown editor ever touched them is gone. If I don’t edit the file outside Scrivener, the annotations stay pristine.
Multi-paragraph annotations, created in an outside editor, stay together after sync to Scrivener.
Good work! Thank you!
The bad news: Other aspects of this bug are still with us. (See screenshots below.) In detail:
Making an edit with a Markdown editor outside (and even downstream of) an existing multiparagraph inline annotation still shatters the annotation, even if the annotation is painstakingly coloured to the exact same colour as a new annotation from external file sync.
Making an edit with an alien editor outside of and downstream of a existing pair of adjacent annotations merges those annotations.
Adjacent inline annotations created in an outside editor are merged upon sync to Scrivener.
Keep plugging at it. You’re getting closer.
[attachment=1]Screen Shot 2020-11-17 at 20.15.47.jpg[/attachment]
[attachment=0]Screen Shot 2020-11-17 at 21.11.58.jpg[/attachment]
Yep, this is only partly fixed because to fix it completely would take a complete rewrite of a large chunk of external folder sync code. I’m afraid I can’t say when that will happen.