Apologies if this has been asked before, I did just do a search on this forum and didn’t find an answer.
So: I have been writing in vim (compiling via pandoc) a lot lately because it’s kind of addictive, but I notice that I do need scrivener-style features for organization… then I just discovered the “External folder sync” bit in scrivener and am quite happy about that.
But the issue is, I don’t like inline footnotes/comments; but I’ve only managed to sync inline annotations (via the option in the preferences), not inspector annotations. I know I can convert them to inspector via edit > substitution, but then if I sync to .md the inspector footnotes get lost. Conversely, the markdown footnotes that I already have ([^footnote] etc.) also are just rendered as plain text.
So, ideal behavior behavior would be: Inspector footnote becomes markdown footnote ([^1]) on export; I suspect that’s not possible. Meanwhile, are there any workarounds or scripting options on the scrivener end to at least automatically convert inspector annotations to inline before sync?
These are some understandable wishes. The main thing you are running into is that Scrivener does not really tap into much Markdown parsing, with a few minor exceptions—and those exceptions demonstrate the limitations of that approach. For example when you use the File ▸ Import ▸ Import and Split... menu command and specify an .md file, you will see a checkbox to Convert Markdown. If you try that, you’ll see it’s next to useless to anyone that actually knows how to convert a Markdown file to something Scrivener could import more completely (like RTF, DOCX or ODT). It basically just converts it to HTML with the embedded MMD binary and then imports that using the text engine’s HTML → RTF mechanism. The limitations of doing things that way are obvious as HTML is not a word processing format in the least. As I recall we might augment it a little bit, but not much as that kind of augmentation is fragile and clunky (literally search and replace functions on raw markup).
There are probably better things we could do, particularly at this point in time, and I think it is worth giving it some further thought for the future.
At any rate, as you’ll note in the user manual one of the stated benefits of using more pure Markdown in the editor is better access to External Folder Sync and integration with other tools that can edit without formatting loss. The more of Scrivener’s rich text toolkit you use to generate Markdown, the less useful the text will be outside of Scrivener. Could we make that better? Maybe, but it would not be simple.
ok, thanks for that answer. I naively thought that since there appear to be so many options for mmd-based compilation, the sync might be able to do this too somehow, maybe using styles or something. But I figure it’s a different process.
A follow up question, though: I notice that the external folder sync completely ignores directories, as opposed to files. Am I doing something wrong there? I’ve already got sort of a folder structure in place and it would be a bit of a nuisance having to redo that, instead of just importing it into the project…
ok, thanks for that answer. I naively thought that since there appear to be so many options for mmd-based compilation, the sync might be able to do this too somehow…
Well there are two problems there. The first is that the compiler is enormously more complicated than this feature. This essentially just dumps your text editor content out into files. There is some very light processing yes, for the inline notation for instance, but this is like comparing a lawnmower engine to a Ferrari’s in terms of what all is going on.
The second problem comes down to that old rule of thumb: it’s a lot easier to make files than it is read them. I could write a little program that writes RTF files with some basic features in less then an hour. It would take considerably more effort to make a program that reads RTF to that same level—this is especially true of any format that has a lot of potential variability in the syntax. Markdown is of course way easier to parse for than RTF, but it’s still a lot of subtle stuff you wouldn’t even really think of until you start getting into all of the possible edge cases people intentionally, or even inadvertently, put into their file. Because it is meant to be a human-friendly format, variability is part of what makes it tick. Just perusing the CommonMark specification should give you an idea of how much parsing you would need merely to recognise a block quote, in all of the many ways they can be formed.
Sync needs to be perfectly symmetric. There is nothing symmetrical about the compiler anywhere in Scrivener in fact. It can do way more than the software can import or even do at all in the editor.
A follow up question, though: I notice that the external folder sync completely ignores directories, as opposed to files. Am I doing something wrong there? I’ve already got sort of a folder structure in place and it would be a bit of a nuisance having to redo that, instead of just importing it into the project…
I can’t reproduce this myself. Container or group items export to the sync folder for me. They may be empty files if you haven’t typed anything into them, but they should be there.
Perhaps you are meaning this more literally, like you’re thinking Scrivener should build a file system hierarchy based upon the outline hierarchy? That’s not really possible since file systems do not work like a “true” outline. I can’t type text into a folder in Finder/Explorer, for instance, or nest a PDF file underneath a MOV file. Scrivener has no such restrictions so such a thing cannot be replicated in this context.