lol. KB, can you say something about what you’re planning in this regard for 2.0? From one of your posts above I had the impression that scriv was going to recognize separators during file import. Would it be too much to also recognize heirarchy via markup?
thanks
That is odd you have are having problems with asterisks and dashes. This really shouldn’t trip up the importer unless it is doing things I’m not aware of. I thought it strictly went over header hierarchy and assembled a Binder outline accordingly. There is a conversion tool which generates asterisks for RTF styling, but nothing that, again to my knowledge, parses out dashes and so forth.
Regarding Windows->Mac, yes you might run into issues there because the two platforms tend to write out files slightly differently. Macs these days use the “standard” method which is also used by the Internet. Windows uses a double-character for paragraphs instead of a single-character—and it is that extra character that can trip up some scripts. Older Macs used another format altogether, but that is largely irrelevant these days.
The easiest way to make sure your Windows files are “Mac friendly” is to make sure that they are saved as UTF-8 encoded with Unix (LF) line endings, when saving out of TextWrangler.
If you can work the bugs out of that workflow, it really is the method for getting separations and hierarchy into Scrivener, OPML aside which is an XML format so not really as useful to humans typing out draft ideas in a word processor or text editor.
Splitting by separators is easy. Say you tell it that “#” is a separator. Then this:
Some text
#
Some more text
#
Etc…can easily be split up into three documents. But hierarchy? How would Scrivener know anything about that? (Bear in mind that it will still use the standard OS X file importer which knows nothing of hierarchy.)
All the best,
Keith
“saved as UTF-8 encoded with Unix (LF) line endings, when saving out of TextWrangler”
amber - thanks for the deets, i’ll continue trying to work within MM import.
“But hierarchy? How would Scrivener know anything about that?”
keith – what if you recognized ## as a second level note just like MM? (and ### as third level etc). What you’d be providing (that MM doesnt provide) is that this would work for any format file that scriv is importing, wouldnt be limited to mac-style-txt files like MM currently requires. That alone would add some importing flexibility because this would then work on ANY of the many file-formats scriv can currently import (doc, rtf, etc).
In other words, scriv currently imports a wide variety of files (doc, rtf, txt, etc etc). In that import, scriv could natively recognize separators and (and ## etc as heirarchy) within the text of the imported file, no matter the file format.
does that make sense? It would eliminate a few steps right away (such as first importing/exporting into textwrangler to get the text file, as currently required via the MM route, when coming from word or devonthink or tinderbox or evernote or any other program that writers use commonly; instead, any program that can export as rtf (which is very common) or straight doc or any of the other formats that scriv already can import, would be supported as a direct import into scriv, right?).
(additionally, in the options, what if you allowed user to self define what the separator/heirarchy symbol or text should be? Not limited to “#” thus, tho that could be the default).
The user will be able to choose what the separator is. However, the feature is mainly aimed at bringing an existing manuscript into Scrivener for editing. The single hash separator is standard in manuscripts; others may use a double line break or whatever. The user will just choose what they use to separate sections, and it will get split up automatically.
It is not common to have different numbers of separators to denote hierarchy - this would entail the user going through the manuscript and editing the separators already there to ensure that they denote hierarchy in some way. But it would be quicker for the user to “import and split” and then just rearrange into a hierarchy in the binder, which is much more visual and thus easier than trying to type different numbers of separators.
All the best,
Keith
also on the export side (exporting back out of scrivener), maybe you could indicate heirarchy with tabs? That would be a kind of “visual” representation of heirarchy on the exported file. (As an option anyway; and also allow user to choose how separators will be indicated on the exported file?)
" But it would be quicker for the user to “import and split” and then just rearrange into a hierarchy in the binder"
I agree that its easy enough to drag stuff around into heirarchy once they’re in scriv. But one thing that importing a heirarchy indicated by ## or etc, allows for, is it allows the user, if user has a file that already has a heirarchy in it, allows the user to not have to lose that heirarchy when importing into scriv.
Otherwise, user has to remember and reproduce that heirarchy in scriv. (remembering is work; reproducing is work – it would be less work for the user to put in hashes (something that can be done by the user while typing up the document (for instance, in writeroom, which is also very popular), or something that could be automated with find&replace features in word processors). Either way if user’s file has hashes, seems like it would be a godsend for scriv to just read them in into heirarchy. (and user doesnt even have to take the intermediary step of first converting to txt via textwrangler, as would be required by MM).
(actually come to think of it, the ‘tab’ thing wouldnt make much difference since multiple tabs would look weird on longer paragraphs 
)
but pls do consider making import more versatile… it seems like such a basic thing to me, to be able to plug scriv in a much more versatile way into diverse workflows… if you’re putting in recognition of markers for ‘separators’, seems to me that recognition of markers for ‘basic heirarchy’ is only a half step away and can help reduce some of the hurdles associated with importing into scriv.