Just to add here, the question is not “is markdown (or tex or binary strings or...) better”, but “can the person who determines whether I get paid open the file?”

The fiction publishing world is cutthroat competitive. Trying to use nonstandard tools / “breaking the mold” adds even more friction to success.

I will find out the answer to this question hopefully later this year. :-)

But anyway, I do use Markdown and I have submitted to contests etc. that require Word formatted files. For the most part it's an nonissue. I can use Pandoc to export to Word, provide the reference file with the correct format, and boom, I'm done. None of the judges of my works so far have ever had any issues opening my files.

I agree the publishing industry will never accept Markdown. That's ok. I can use the tools I like and still produce what they need to do their part of the job.

I agree, and I draft my own fiction in emacs. The cost is lower to use my preferred editor, then do the post-hoc formatting adjustments once in Word.

For a novelist, though, the editing process is quite iterative: make changes, send them to your editor, they send it back with comments and inline track changes and so on.

Don't get me wrong, I'm an advocate for using tools you're most comfortable with...whatever gets you writing! But these small things can throw a wrench in the process. It sure sucks to have to do edits in Word!

Good luck with the publishing project, though, it sounds like you're pretty far along!

Unrelated, but what do you write? (Feel free to contact me on Keybase if you prefer, username is in profile.)

I'm an author and an software engineer. I can see why Markdown could be slightly better for a writer - but not much better - and honestly it seems like a step down for an editor.

Primarily, all a writer does is write plain text. Probably less than 1% of sentences are anything other than plain text.

There's not a lot of headings or titles. There's not a lot of italics or bold text.

What else is there? What am I missing? What's the benefit?

You just sold everyone on markdown. This is the whole point. All the crap MS Word adds to support formatting and visual styles is in the way. With markdown you focus on the actual text. Exactly what an author should want to.

What exactly does MS Word add over markdown which matters to an author? I am talking about the writing experience. You could always export to docx.

A table of contents you don't have to manually maintain. Built-in interface to insert special characters you can't type with the keyboard. Automatic grammar checks. Auto-corrections. Macros. All of the above in one program instead of a hodge-podge of programs. Being able to send and receive documents from people with no conversion needed.

No offense but you don't sound like someone who writes a lot?

"What does MS Word offer over Markdown" isn't a good question, because they're not the same thing -- Word is a program and Markdown is a file type. There's nothing that stops a Markdown-based editor from having a full set of features. I've very rarely felt that I was missing out on features when using iA Writer or Ulysses compared to a word processor, although occasionally I wished for either the kind of document juggling that Scrivener is so good at or actual full-blown text editor features like BBEdit. But I haven't reached for an old school word processor as my first choice as a composition tool in... probably 15 years. And I definitely do write a lot.

The most obvious WYSIWYG competitor for novelWriter is Scrivener, which is similar to Ulysses -- and also shares the limitation that it can only export to Word rather than import. Nevertheless, its testimonials page is filled with praise from people who arguably write more than I do. :)

Writing a table of contents is my formatters job, not mine. It takes place after both my editor and my proofreader have completed their jobs, at which point I don't touch the file any more. If you format your own, then you're already in an small niche.

Some people may need "special characters" they can't type, but I have keybindings for the characters I use.

Grammar checking and corrections is my proofreaders job, not mine. It happens after I've converted my document and sent it off.

Macros are supported in pretty much every editor I've ever used for plain-text. I use lots of macros, but exactly zero of them for my novels.

I don't need to send and receive documents with no conversion needed. I do one export when I'm done with my first draft, and then I edit and do one more export before handing it over to my proofreader. Then, sure, I review those changes in Librewriter. The proportion of my time that takes is tiny. It'd be nice not to have to, but I'd take that over having to work in a word processor during writing any day.

> No offense but you don't sound like someone who writes a lot?

As someone who has written several novels, that's how your comment came across to me. At the same time I know novelists range from the pen and paper type (e.g. Gaiman, King to give two examples discussed in this thread) up to wanting word processors with all bells and whistles - it's very much down to taste.

* Table of contents: solved by Pandoc.

* Inserting special characters: personally I don't find those "character choosing" windows to be very convenient. Hunt and peck is a slow way to type! Anyway, you can do this in Markdown with either Unicode (if you have the right keyboard) or you can write HTML escape codes (&tm; etc.)

* Automatic (grammar/spelling). I don't like check as I type, but sure. Anyway, Emacs provides this if I want it.

* Macros. Hello? Emacs? (Also, Pandoc has a scripting interface.)

I may not be published yet but I've written my own book. I've also published books for other people. I did both of those with a Markdown-based toolchain. It works.

Edit: Just to prove the point: https://www.amazon.com/dp/0692553916 . Go see for yourself how the book is formatted.

The "inserting special characters" one is a bit of a "eh?" for most of us Mac users, I think, since most special characters can be typed using the Option key and the character chooser (which is indeed not very convenient!) is system-wide and should work in a native build of at least the GUI version of Emacs. But, yep -- Markdown and Word aren't the same categories of things. How comfortable your Markdown editing experience is depends on how comfortable your Markdown editor is.

(Also, I wrote a Markdown-to-ePub script, too! Although I don't think anything I've got up online uses it anymore.)

pandoc, emacs, and scripting are _not_ a realistic option for most writers. They're writers, not programming geeks.

I'm a Markdown fan, but really there _are_ better solutions for book writing that maintain the ease that Markdown brings. Things like ASCIIDoc.

And in emacs, you can insert essentially any Unicode character with `C-x 8 RET`...add swiper and you're off to the races :)

Also, if emacs was good enough for Neal Stephenson, I'm sold...though I hear he uses Scrivener now!

Why would I want to write my first draft in a different tool than my subsequent drafts? Nobody cares about visual styles, but my editor sends back their thoughts with inline edits and comments in Word. It's so much easier to edit in Word. I'm a huge Markdown fan, but it raises the question:

What does Markdown get me that makes it worth switching to for the first draft only?

Many writers intentionally separate tooling to force workflows, even at the point of great inconvenience if it provides for an environment they feel is more conducive to writing. This is generally far more important than whether or not getting it into a format that editors can work with is extra effort or not.

Hemingway famously favoured pencils for his first draft and switched to typewriter for his second.

Gaiman and Stephen King uses pens for at least their first drafts. Gaiman expressly for the reason that he believes it force him to be more thoughtful and forces him to go back and rewrite the full book word for word rather than going back and forth to edit. King switched to pens after his car accident.

JK Rowling wrote Harry Potter with pen on loose sheaf paper.

Writing novels is intensely personal, to the point where writers will insist on specific brands of pens or specific models of typewriters. E.g. Danielle Steele has used 1946 Olympia's throughout her entire career.

i am probably the wrong person to respond because the reason i prefer a plain text editor is that that's what i have been using for all my work until now.

i am not yet there in the process, but i won't be using plain text/markdown just for the first draft.

when i get back that word documents with comments from the editor, i'll look at that like a read-only copy, and actually make the required edits in that same plain text editor.

while it may be easier to make edits right in place in the word document, it is easier (for me at least) to keep a history of changes with plain text documents.

otherwise i'd agree with you. if you are going to end up editing in word, may as well start with editing in word. for me the goal is to avoid using word/libreoffice at all.

From your parent's comment, I think this is the key statement:

> what an author should want

That is normative / prescriptive attitude, and seems to gatekeep who gets called "an author."

On the other hand, I think the biggest challenges most writers have is getting words on (digital) paper, regardless of the software.

I am also unconvinced that there are any practical benefits (for me) to using Markdown in particular, instead of whatever is closest to hand and offers the least friction...use what works for you!

MS Word does add word processing. E.g. your straight quotes will be contextually converted to the correct left/right quote, your hyphens can become em-dashes, etc.

Ha! This is a really interesting perspective—I think you're saying, "it's all plain text, so there's no advantage to using Markdown instead of docx".

I think others have an opposite view, but on the same grounds. The argument seems to be: it's all plain text, so docx is overkill, so markdown is more technically efficient!

There's some benefit to using the tool I know best (emacs, for me), so it's nice to use a "native" format that also gives me my usual keybindings, macros, etc.

But there's no doubt it just offloads the inefficiency to a different step of the process. I'm more comfortable with inputting text, but it requires post-hoc reformatting, and I'd have to use a different word processor for post-editor changes...

The "markdown is a more efficient solution from a technical perspective" argument doesn't hold a lot of weight with me...the practical overhead of docx is minimal, so unless you prize technical purity over all else, I don't think there _is_ a benefit.

The benefit is the rest of the pure text toolchain. Like being able to use Git. I can confirm, for example, how long a typo has existed in my book by looking at the Git history. Maybe that's a bit academic, but you get the point. I have the complete history of everything I've ever written.

Another example: because formatting is reified in Markdown, I can grep for it. Did I misuse italics? With one command I can find every single place where I used italics in my entire book. I don't think you can even do that in Word. Good luck reading a multi-hundred page manuscript to find all of the places you may have made the same mistake.

Another example: Word provides styles, but honestly, who has discipline to use them? Most people I know manually insert page breaks, centered text, and X number blank spaces at the top of a page to make a new chapter. In Markdown, all of my markup gets converted into Word styles automatically and then I can create a reference doc to apply the style I want. I'm writing semantically correct styles in my documents all the time with no additional effort.

Well, to be fair, MS Word maintains a full history of every edit that was made.

And, find-and-replace for specific formatting is supported out-of-the-box.

Finally, cmd-i / cmd-u / cmd-b are pretty easy default bindings, and setting up shortcuts for more intricate, specific styles is straightforward in Word.

I share your preference for using an efficient tool—I'm a die-hard md+git practitioner. But the "most people I know" argument is not a good basis for rejecting real, rich features in software that works well for other people.

I am also curious: why do you care about semantic correctness? It's OK if that's just your preference, but it's not something that moves the needle for me....I'm not sure why I should care!

(edit to add: my comment sounds glib and a little sharper that I intended. That wasn't my intent!)

I think version history doesn't work the way you think. It seems to be supported when you use Microsoft's cloud storage product (which I do not use):

> Version history in Office only works for files stored in OneDrive or SharePoint in Microsoft 365.

> https://support.microsoft.com/en-us/office/view-previous-ver...

Or alternatively you can sort of hack it with track changes, but it's not automatic and there is a long list of caveats. In short, track changes is really intended for a single round of changes on top of a base document, not for permanently tracking the changes on a document over its entire lifetime:

https://support.microsoft.com/en-us/office/view-previous-ver...

Now maybe a Word expert will come along and tell me how to do it properly. :-) But even if they do that sort of proves my point, which is that Word is a large, complex piece of software and even if it hypothetically supports some feature, doesn't make it intuitive or easy to use in that way. (Or that you won't hit a bunch of corner cases when you try to use it.)

I do stand corrected about the find-replace formatting, so thanks for that. But on the other hand, I don't think it really contradicts my point either.

To be clear, I do think Word serves its user base! For low- to moderate- tech savvy users, it's does exactly what it needs to. And I'm not saying everyone should switch to Markdown. But for those of us who have the technical chops to go beyond it, there are some real advantages to working with other tools that shouldn't be discounted.

Well said! Though, I would say that this statement is a good description of git, too:

> a large, complex piece of software and even if it hypothetically supports some feature, doesn't make it intuitive or easy to use in that way. (Or that you won't hit a bunch of corner cases when you try to use it.)

A takeaway I get from this entire conversation is that the real pain point is not the drafting stage, but the editing stage. The latter is (a) collaborative, with (b) non-technical stakeholders...there doesn't seem to be a good way to both use my favorite editor, AND play nicely w my editor's stack (or lack thereof).

Good thing I don't have an editor...that would require me to actually write things :D

> MS Word maintains a full history of every edit that was made

This is only true while track changes is on, correct? Like can I see the state of a docx as I was writing it last month/year?

I don't use Word so I can't say!

But if you cared about the history, why wouldn't you always turn them on by default? "Full history" in git is also an opt-in model for maintaining a history...

I write books in Vim. The way I work is that I do it all in plaintext until the final edit. Only after that do I add formatting (could be .docx or Markdown or whatever the editor expects).

What happens when your editor requests changes? How are those edits communicated to you, and how do you integrate them back into plaintext?

(Serious question—a big pain point for me is the choice between using my preferred tool to start, then switching to a bad tool later; or, using a bad tool the entire time)

All edits in plaintext on both sides until the final draft. Yes, I know this isn't the standard way of doing things but it isn't so much because I'm a Vim cultist or anything. It's only because I can yank, insert, and navigate the text so much faster than with something like Pages, MS Word, or Scrivener.

Another way that seems to work well for some writers and editors is a shared Google Doc.

This sounds silly but as an author myself it's extremely important that I know what the story looks like to a final reader while I write it. It's like dogfooding my own prose. Too many short paragraphs, or too many long ones, or strange gaps, etc. are much more evident to me in docx or scrivener or any other text processor.

I could never get over Markdown; Markdown doesn't show me the user experience of my own code(writing), while word and scrivener will show me instantly.

My favourite talk on this topic is "Emacs for writers": https://youtu.be/FtieBc3KptU

If you are working with plain text, use something that excels at working with text. I saw another of his talks, and how he works in Emacs is amazing.

Consider a book like The Lord of the Rings. It has gone through countless revisions and corrections. With markdown and git you could track those changes and corrections over time.

Yes, you or I could...but Tolkien was much busier writing and world-building, and I seriously doubt George Allen & Unwin (the publishers) would have acceded to conditions on how the manuscript was sent to them!

Also - doesn't MS Word have revision history?

Geez 99.99% of a Nobel is just plain text. MS Word adds no value. Getting plain text into MS Word is not rocket science.

The point of using markdown is that you got many tools which are superior is aiding in you writing process and organizing your text.

The final format is much less important than whatever aids your writing process.

I have tried using traditional word processors for writing novels and I cannot say they measure up to tools like Ulysses.

> MS Word adds no value.

Word automates a lot of things in the editing cycle of a novel. Word's "Track Changes"/"Accept Changes" tools and the workflows they enable are by far the most common in a number of industries, but especially in edit workflows of most major publishers. That's why the Word format specifically is often requested/required, because people know and understand those tools and already have processes/workflows built around them.

The closest equivalent tools for plain text are source control systems and text diff/patch. Those tools are great (and arguably fit some definitions of "superior", especially in capturing history earlier in the process and keeping history longer after the process). They are also nowhere as ubiquitously installed as Word, and nowhere near as easily taught (or already known/understood) as Word in today's world.

Those "edit cycle" needs maybe aren't a huge reason to do the initial writing in Word, but they are certainly many steps above "no value", and thus the noted restriction that no matter what tool you use for the initial writing, if it doesn't have an easy Word export to get it started down the edit cycle path then it doesn't have an easy fit in today's publishing world.

I'll tell her to let her editor know that. Lol.

This can be accomplished by exporting to PDF

exporting to pdf is exactly what you don't want as an editor receiving files from a writer.

Unless you're already a big-name author you rarely get to choose. Docx will generally be an option, and if you're lucky a few other formats.

How is a copyeditor supposed to manage a PDF? PDFs are generally a huge no-no in submissions. (Source: I write short fiction & my short fiction has been published.)

I guess their editor can just cut and paste to Word if he really wants to make corrections.

> their editor can just cut and paste to Word if he really wants to make corrections

Is it sarcasm? I mean... make corrections/changes is what an editor does.

Hes, it was sarcasm. A write-only format is the worst way to send a novel to a publisher/editor.

From the documentation:

> The core export format of novelWriter is HTML5. You can also export the entire project as a single novelWriter Markdown-flavour document. In addition, other exports to Open Document, PDF, and plain text is offered through the Qt library, although with limitations to formatting.

So it seems like it can export to Open Document, which seems to be well-supported[1]; including Microsoft Office support.

[1]: https://en.wikipedia.org/wiki/OpenDocument#Application_suppo...

If she sends ODT to her publisher or editor, they will laugh at her and throw it in the trash. There are very specific rules about this stuff and no wiggle room for interpretation. It _has_ to be in docx format or it's not getting read.

She's correct. Only a programmer may entertain the idea that editing markdown is superior to any visual editor.

> markdown is a superior way to write

Is it though? I don't have any experience with book authoring but I would expect stuff like Geronimo Stilton to be hard to produce with markdown: it is peppered with creative text highlighting (e.g. words written in a custom cheese-pattern font) and this is common in primary school geared books.

Even decidedly grown-up books like GEB might have illustrations and diagrams, and it's important to consider where said illustrations go - they must fit in a physical page.

There are also other small quality of life things that word does automatically, e.g. replace ASCII 0x22 (keyboard quote) with 0x201C / 0x201D (left and right double quotes, respectively), etc.

Don't get me wrong, I love to use markdown for programming documentation and it's pretty good for that, especially when you adopt flavors like GFM. But I'm legitimately curious what makes one consider markdown superior for book writing. It just seems like it would have a different set of priorities.

I think that House of Leaves can be left as an unaddressed edge-case for most novel-writing tools.

Even ignoring diagrams, etc, there's a reason that like word processing applications are killer apps for personal computing. WYSIWYG is a pretty convincing abstraction!

And yeah, you have the invisible format issue but at least you can make tables and resize them with your mouse.

Markdown's value add comes from having really good implementations to transform it into rich text, and being "unambiguous" (it's not really in a lot of cases but there aren't many great alternatives with widespread implementation).

But like... Word is pretty magical overall.

Coming up with the text and doing the visual layout later are often separate step. And author does not do all the visual layout.

Yes, almost publishers accept Word documents only, and that's why I've built DocxManager (https://docxmanager.com/) on top of Microsoft Word. ;)

Basically, it's an outliner/corkboard/project manager for all kinds writers who uses Word.

Windows only. Bummer. Completely understandable, but bummer. A lot of tools can output .docx files.

I agree with her - markdown is totally not a superior way to write. It's a good way to mark up text, but writing isn't just marking up text.

When writing you want a tool focused specifically on writing an organizing text. Programs like word is too focused on formatting and visual aspects.

Markdown would be much better for authors. Just because they have become accustomed to something else doesn’t mean that something else is better.

Just watching the mess my dad makes when writing books in Word makes me convinced that anybody who claims Word is superior for an author simply have never watched and author in action.

Acknowledge having an inbuilt export would be preferable but for what it’s worth; If you’re a dev it shouldn’t be too hard to leverage pandoc, especially coming from a clean text based format.

Something like:

$ brew install pandoc (install on macOS)

$ pandoc -t docx filename.md -o filename.docx

Ref: https://opensource.com/article/19/5/convert-markdown-to-word...

This is now significantly more steps than downloading Scrivener.

Unless it's got better Scrivener is pretty awful though - bought it for my first book and gave up, both books I've written were written with other tools

Interesting, I've written two novels and over a dozen radio drama series in Scrivener. Currently using it to finish first draft on a spec film script. It's pretty fantastic. Interested to hear why it didn't work for you - especially if the alternative is word.

Cross platform support (including iPad), saving direct to dropbox, full screen distraction free mode, easy sorting of chapters / scenes, rapid offline export to PDF (unlike say Celtex). Scrivener just blows everything else I've used to write out of the water.

What did you use instead?

One was in asciidoc (the publisher's tool of choice), the other was in pages (only a 10,000 word book)

Working draft for current one is in Ulysses but I’m not feeling it ATM so might switch

They're technical books rather than novels so although I prefer markdown I find it doesn't quite stretch far enough for me

However, since NovelWriter is GPLv3 licensed, they could in theory incorporate code from Pandoc, which is GPLv2 licensed, directly into NovelWriter.

I think you guys are missing the point. The point isn’t “how do we get from markdown to docx” but rather “why doesn’t this tool support the format my publisher expects”. Yes, pandoc is amazing, but the product needs to support exporting to docx for the publisher so that the user of NovelWriter feels supported and empowered to write.

TeaDrunk said it best: it’s now significantly more steps the user shouldn’t have to do.

This is the correct take. If it's so easy to do then there should be a button or menu option that does it.

That’s what I am saying. Integrate Pandoc into NovelWriter so that users can export directly to docx.

You and parent commenter seem to think that you are disagreeing with what I said but we are agreeing.

or just use PanWriter: https://panwriter.com/

It can export to ODT or HTML, both of which can be imported into word, or moved over by crudely cut and pasting into Word.

I think the bigger issue if she already likes Scrivener is that if that is the functionality she wants, then unless she wants the flexibility of being able to customise a tool or process Markdown files with code or switch to Linux etc. is something she wants, then it's not likely the tools you've pitched, or this one, will be an improvement.

I write in Markdown myself, so I absolutely sympathise with your POV on that, but I think the "rock solid word export" is more of a way to get you off her back because it works.

You also need a way to import changes from edits. Word's track changes feature is vital in professional contexts, even though it is not always intuitive. Once a manuscript gets to the editing stage, tracking revisions, comments, suggestions, etc is extremely important. I suppose at that stage, you could just move away from a tool like this, and just use Word, or Google Docs.

Trying to unseat Scrivener is like competing with IntelliJ.

Ok, we're going down the hole of analogies a little too far but VS Code and the world of language services is a pretty decent replacement for a lot of use cases outside of IntelliJ's core Java strength.

Every top dog eventually gets cut down by _someone_ over time.

Scrivener does in fact have competition. (Highland 2 for screenwriting for example.)

As a competitor to Scrivener, I'd love to know why you think that.

(I just deleted a paragraph of text so that I don't influence your response with my own opinions.)

I applaud the author for keeping everything text file based.

In general, I think we should strive for non-proprietary, standard file formats.

Isn't docx far too one-sided and controlled in that regard? I wonder if anyone has some info on the "state of affairs" for the "document format race".

None of this matters because the industry relies on docx (and it's a crusty, oldschool industry so good luck changing that).

A minimum for a novel writing tool is that one can actually send the novel out in a format where your agent and editor will read it. Otherwise you're not getting that novel published.

If we're being fair, docx (or rather, tools that write docx files) offers a lot of tooling out of the box that is useful for proofreaders, editors, and typesetters. Revision history, suggestions, and non-printing comments are all incredibly useful.

This is correct. Any writing software that aims for an audience larger than HN needs to have a very robust docx export capability.

My partner tells me that it has to be formatted a certain way down to the font and line spacing too or they won't accept it.

I'm cracking up at all these comments suggesting that her recipients brew install pandoc lol. Good luck with that.

Depends on what industry… O'Reilly relies on Asciidoc

I see you hate the Unix philosophy....for conversions use pandoc. A Song of Ice and Fire was not written with Word.

> A Song of Ice and Fire was not written with Word.

When startups haven't even started up yet but are worrying about how they can scale to billion-dollar unicorn level, a common refrain on Hacker News has been "you are not Google."

Allow me to give you the fiction writers' equivalent: you are not George R.R. Martin.

The output is md....dont you think you can convert that too let's say docx? You don't even have to be Google todo that.

And if you want to let it proof read by George R.R. Martin you can even convert it to WordStar....magic eh? Pandoc can do that...your MS Word too?

You're missing the point that people are trying to make here.

Yes, it's possible to convert Markdown to a Word file, with a variety of tools. You can use Pandoc to do this if you are the sort of person who is comfortable using tools like Pandoc. I can do that, along with all sorts of other things, because I am that sort of nerd.

However, most fiction writers and editors are not that sort of nerd. Most people don't want to use Markdown in the first place. Of the people who do want to use Markdown, not all of them are that sort of nerd, either. They want an "Export to > DOCX" command in their editor, not "save the Markdown file, open your terminal app, change to your documents directory, and type "pandoc -o my-novel.docx my-novel.md". (And that's assuming they're not doing something like, well, what NovelWriter does, saving individual chapters and perhaps even individual scenes as independent files.)

Look, I love Pandoc. It's great. But it's not a tool for everyone. If someone is trying to embrace the plain text lifestyle with a tool like NovelWriter but pointing out not being able to export to a Word file is a problem for them, asking "are you comfortable with Unix command line tools" and then telling them about Pandoc if they say yes might be a great idea -- but starting out with "obviously you hate the Unix way", maybe not so much.

> you can even convert it to WordStar....magic eh? Pandoc can do that.

No, in fact it cannot. :)

> (And that's assuming they're not doing something like, well, what NovelWriter does, saving individual chapters and perhaps even individual scenes as independent files.)

This is totally unrelated to the gist of this thread, but I just wanted to point out that novelWriter's project builder outputs to a single file, which can be markdown, ODF, PDF, HTML, and others. Pandoc could then make a single DOCX file out of that.

Your point still stands that this is too complicated for the average user, but I just wanted to mention this since it might make a difference for technically minded writers considering novelWriter.

That makes sense (I figured novelWriter did that, since it looks an awful lot like an attempt at a Markdown-based answer to Scrivener and that's how Scrivener's "Compile" function works), and I suspect it won't be too difficult for novelWriter to add other file formats to its exporter. So not being able to output DOCX is probably not a long-term issue, unless the maintainers have a philosophical objection to it. :)

First, your probably right and i may/really have missed the point.

Second...it really cant.

Shame on me, and sorry for my tone.

How are you going to handle editor comments without losing history?

When you too can afford to pay your editors, proofreaders, and publishers to accommodate your unique file formats and the associated changes to their workflow, you too can write in WordStar.

Since you obvious don't know what unix philosophy is, it's a md writer..that's it, you want to convert it..take a converter like pandoc. If you really think every writing program should have it's own converters..well then you end up with less interchangeable stuff. One tool for Writing another one for conversion..is that so complicated?

For a layman, err, editor? Absolutely. It's a completely different workflow than what they're used to.

The Unix philosophy has nothing to do with this, since we're not talking about programming, we're talking about writing.

>since we're not talking about programming

Has nothing todo with programming, a real hammer is better as the backside of an axe. A Specialized Knife is better then a Swiss-Pocket Knife. One tool for one job but make that job perfect.

Ever see a framer’s axe? It’s one part axe, one part hammer. It’s perfect for framers - they love it. It’s one tool which lets them chop, modify, remove nails, hammer in nails, whatever they need to do, without having to carry 4-5 different tools.

The idea that a specialized tool is always better than a multi-tasking tool is simply not true. One must only look at the popularity and utility of leatherman multi-tools to see this to be true.

Even in programming circles, one needs only to look at how many options there are for ‘ls’ to see that “one tool for one purpose” is not always the best thing.

>The idea that a specialized tool is always better than a multi-tasking tool is simply not true.

It is hence the name specialized, but if you have to live with a all-round tool then that whats you have.

>one needs only to look at how many options there are for ‘ls’ to see that “one tool for one purpose” is not always the best thing.

The gnu or the bsd one ;)

If you have an editor, you need two way communication -- they are going to make changes in your word document, using track changes, so you also need to be able to convert back.

To be fair, docx is non-proprietary. And as an ISO standard, it is a very standard format.

Infeasible is maybe a stretch. However you will need to have a multi-step "Export for Publish" workflow which is definitely a hurdle. However assuming that 95% of the time is spent writing it may be worth it if you like the tool.

The hardest part of writing a novel is definitely not converting it to docx. I can't even express how crazy this discussion sounds. It's like people who post on writer's forums about how they have an idea for a novel and ask what the best way to get it published is.

Docx might be an appropriate format to communicate with a publisher. But to my very limited knowledge Markdown is a good choice for the initial authoring process. As it can easily be converted. These days publishing happens on all sorts of platforms and the end product needs to be prepared for the press, ePub, Kindle, PDF, audiobooks, etc.

Until the distribution is decided my intuition is that Markdown provides this needed flexiblity.

Use pandoc to export or transform it (if you can).

it says it can exporting to ODF, but without much formatting requiring additional editing after conversion. instead it recommends exporting to HTML, and then importing that into writer or word for better results.

but i could not tell from the docs how to get the end result into something like standard manuscript format without manual processing.

found the answer: http://www.autodidacts.io/convert-markdown-to-standard-manus...

should be easy to implement using pandoc since the underlying code is python?

Yeah I was surprised to see it didn't use pandoc for exports. I'm not sure why, and all these issues about exporting to word wouldn't exist.

Might be due the GPL license of pandoc, this is a copyleft type license, requiring any code that is built with pandoc to be described, made available, and released under the same license.

https://github.com/jgm/pandoc/blob/master/COPYRIGHT

Given that novelWriter itself is GPL licensed, I doubt this is the problem. More likely it was a choice to avoid needing pandoc as a dependency, either explicitly (bundled or integrated in the code somehow) or implicitly (calling to the system's pandoc install), as pandoc is written in Haskell and kind of a PITA to build or integrate in that way.

Since you can already export to a single ODT/PDF/MD, the benefits of additional pandoc integration are probably diminished.