Adds: Importer (docx, html, opml, …)

[olivierkes]

The branch feature/importers has been created based on @camstevenson's work on OPML import (#192). Long life and prosperity to him !

I'll will now work on that branch to create an Importer similar to the Exporter. If I create only a Markdown import, then using pandoc we can import all the formats listed here.

Current ideas:

• Being able to preview the import (by creating a temporary model, and showing the import in outline view / tree view / flash cards), before actually importing it.
• Having an option to create a "scene split" or "folder split" by string expression or regular expression
• Import a whole folder structure, each text file is a scene
• Markdown import

So my questions for you:

• What ideas do you have for the importer? What is necessary, what is to avoid?
• How should a markdown document be imported? My current idea:
  • A title with subtitles in it is a folder
  • A title without subtitles is a scene

Thanks for your feedbacks :)

[anicede]

I've been wanting the ability to import either markdown or plain text.

I do use #Chapter and ##scene fairly often, so your current idea would work for me, and I could adjust my workflow to do that consistently if required for importing.

Another thought is the ability to cut a scene at a selected point and create a new scene containing the text below that point. One of the few functions I do miss from Scrivener. It made the importing of a single file containing everything quite manageable.

I do sometimes end up with work simply as markdown files within folders, though (I did that a lot in an attempt to emulate Scrivener as best I could before I discovered Manuskript). The ability to import folders (=chapters) and files (=scenes) in this format directly would be extremely useful.

[olivierkes]

Thank you for your feedback and ideas !

Another thought is the ability to cut a scene at a selected point and create a new scene containing the text below that point. One of the few functions I do miss from Scrivener. It made the importing of a single file containing everything quite manageable.

How do you signal the cut?

I do sometimes end up with work simply as markdown files within folders, though (I did that a lot in an attempt to emulate Scrivener as best I could before I discovered Manuskript). The ability to import folders (=chapters) and files (=scenes) in this format directly would be extremely useful.

Good idea !

[gedakc]

@anicede Another thought is the ability to cut a scene at a selected point and create a new scene containing the text below that point. One of the few functions I do miss from Scrivener. It made the importing of a single file containing everything quite manageable.

@olivierkes How do you signal the cut?

What about using three "-" (dash / hyphens)? For example "---"?

In Markdown these become a <hr> tag in HTML.

---

^ See horizonal line above.

In my EBookGenTools project I use three hyphens to indicate POV/scene breaks.

[anicede]

@olivierkes

How do you signal the cut?

In Scrivener it was done piece by piece from the menu: Split at cursor/Split with selection as title were the options, if I recall. I mostly just Ctrl-K'd through my file until it was cut up to my requirements :)

An automated 'cut this entire file up into scenes at the defined signal' function is intriguing, however. How to title the scenes, though? Perhaps take x number of characters from the beginning of the scene to name them?

@gedakc The three hyphens would make the most sense as a cut signal, but the ability for the cut signal to be user defined would be useful also (I use *** for my scene breaks/horizontal rule so I can search & replace any instances of -- in my writing with an emdash, and *** is a common plain text scene break for non-markdown users).

[olivierkes]

Thanks for your ideas. I'll work on that next.

I now have a somewhat working OPML importer:

It allows to chose format (only OPML for now), then a file, then preview the import, and finally do the import.

@camstevenson I had to remove the {lf} trick for now, because it would fail with OPML files containing line breaks (for example this one). We need to find a different solution to preserve line breaks in xml attributes.

Also, with OPML, is there any consensus with the names, except the <outline> tag? I've seen you used _note attributes, but other will do otherwise, right?

[olivierkes]

We need to find a different solution to preserve line breaks in xml attributes.

Actually, if I convert your document through pandoc (pandoc "End Plan 2.opml" --standalone -o EndPlan.opml), then we can import it with lxml and it preserves line breaks. They are stored as 
 in the attributes.

(By the way, pandoc also uses _note so this is a standard?)

[camstevenson]

@olivierkes your dialog is awesome.

I'll look later and see why the {{lf}} trick isn't working for your test doc. Maybe it's simply a matter of using instread of {{lf}}. Not sure though until I look.

_note seems to be a de facto standard. Scrivener uses it, along with every other outliner I've used. The only other one I'm aware if is a color one (I don't remember offhand what the actual attribute name is). It's used to select the color of a card for organization. Scrivener emits this, or at least it did last time I looked.

On a side note, I'm debating releasing my eclecdec Android version as GPL, in which case we could collaborate on what additional useful attributes we could agree on to allow for a rich interchange. The idea would be quick cards written on the phone and fed into Manuskript for heavy lifting.

[olivierkes]

Thanks !

On a side note, I'm debating releasing my eclecdec Android version as GPL, in which case we could collaborate on what additional useful attributes we could agree on to allow for a rich interchange.

That sounds great !