This is a request to add (for us programmers) “import” plugins.
The general idea is to segregate the code that parses the various import formats and creates RTF files in a user’s project from the rest of Scrivener and develop an externally accessible API to that functionality. Yes, this is probably pretty difficult (or, at least, merely time consuming).
For example, say I have a certain amount of research in my field that is in some (not obscure to me) domain-specific format. To give an example, perhaps I have some Balkan folksongs transcribed in Musicode (what’s that? You don’t want to know) and I would like to import them as images of typeset scores. Whew! I could ask Keith and Lee to please support Musicode import, but they wouldn’t (and they shouldn’t). Or I could whip out the documentation on import plugins and write a plugin that takes a file or a directory tree of files and parses the Musicode format, creates the images of the typeset scores by calling my music formatter (LilyPond, for example), and then imports them into Scrivener. Done. Or protein molecules. Or DNA sequences. Or star magnitude data. And on and on…
And Scrivener would not have to support any of it. That would be handled by whoever wrote the importer. Some group of musicologists or biochemists or geneticists or astronomers, etc. with access to some coding skill. They would know the details of the format conversions and they would supply the importers to their consumers.
You might say, you can do that now, just not automatically. True. And that’s the point. I can probably find a way to do it by hand given Scrivener (and the rest of my support OS of choice) today. But it is probably laborious to the point where I cannot (or will not) even attempt it. Writing an import plugin solves my problem and potentially the same problem for other researchers in my field, who are, by the way, potential Scrivener customers.
It would increase the usefulness of Scrivener for research a thousandfold. And increase Scrivener’s customer base.