# Could lightweight markup text files and a version control system replace MS Word? [closed]

In every organization and program I've worked in, on, or for, Microsoft Word has been the ubiquitous means of capturing prose--be it engineering memos, documentation, white papers, specifications, plans, etc. The only tools/applications/medium that can even begin to challenge its dominance are email, which specializes in rapid and temporal communication rather that the historical, for-the-record niche of Word, and PowerPoint, which I can't even get into right now but that mostly suffices to convey superficial understanding to people who only kind of care.

The reasons for Word's dominance, or that of word processors in general, seems obvious: word processors create documents and books and papers--the primary means of non-verbal communication and lowest-overhead means of widely disseminating complex ideas.

But when used in a typical work-group environment (i.e. not at home, not for writing your novel), Word has critical blind spots. As an engineer, the most obvious are a lack of integrated version control, of the ability to easily see was-is changes and of a means for teams to concurrently work on a document without stepping on each other's toes.

I realize Word used to have embedded version control, but I don't know of people ever using it, mostly because they didn't know it existed or because they were paranoid about shipping the final product without stripping the historical data (and either way the function has been removed). And I know Word has track changes, but that tool requires the user to remember to turn it before editing or to perform a non-intuitive and often confusing document comparison (which gets worse when comparing a baseline to multiple, independently edited revisions).

On the other hand, a benefit of modern word processing is the ability to customize formatting, and for certain applications this freedom is paramount (although most professionals use Quark or Illustrator for serious graphics-arts-type page layout). But for many use cases (e.g. technical specifications, analysis reports, plans, or procedures), where content is king and presentation is a means to organize and ease the digestion of dense technical material and not the ends, the opportunities to endlessly fiddle with formating generate a cost that outweighs the benefit. Furthermore, the binary file formats of .doc, .docx, and even .rtf render traditional version control and diff programs useless.

So I find myself wondering if there's an alternative solution that can meet the needs of the large technical community currently using Word as their word processor and email, fileservers, or SharePoint as an ad hoc version control system. For this use case, I only see a couple top-level requirements (but am interested in anything I'm forgetting):

• allows basic formatting of text, defined as basically everything that Markdown supports plus ideally the math formatting of a LaTeX-like system, and tables
• stores content in plain text format so they can be efficiently tracked in a version control system designed for source code (Mercurial, Subversion, Git, etc.), diffed easily, concurrently edited, and then accurately merged.

I've considered Wikis, which might be a good option, but I don't have enough experience with how they handle concurrent editing and they don't seem well suited to branching and merging as collaborative teams finalize a product. Plus the lack of positive canonical control over the official baseline is a must for something like a specification and the ability to quickly revert is an insufficient control mechanism. After all, the spec is a contract.

In using Stack Exchange, I've quickly become both familiar and enamored with Markdown. Unlike the traditional binary file formats, Markdown is plain text and readable as such. However, when rendered in a browser or appropriate text editor it supports a fairly rich ability to customize formatting and presentation. Furthermore because it's plain text Markdown text files could be controlled within a modern DVCS framework, which could manage diffs, concurrent editing, versioning, etc.

Could a system based on a a light-weight markup language and a VCS serve as a suitable replacement for MS Word in a large number of applications, while simultaneously providing additional critical functionality that is sorely lacking in the current tools? What critical features of word processors am I ignoring that this new approach could not replicate? What would be the obstacles (both technical and cultural) to adoption of a radically new paradigm for generating documents?

-

## closed as primarily opinion-based by Journeyman Geek♦, Tog, DragonLord, gronostaj, BreakthroughJul 28 '13 at 5:21

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

For what it's worth, you hit the exact same points I make when I ask to not use Word to do engineering documents. Usually, people just laugh. "'Word' is the corporate standard." As if that makes it's gross flaws any more acceptable. –  Bruce Ediger Jun 29 '11 at 3:57
Obstacles include tables with advanced formatting, headers and footers, foot notes, automatically generated indexes and advanced formatting like aligning images, inline boxes and so on. Basically evwerything you need when handling paper, and then some. What you want is actually called LaTeX. If you supply your users with well thought-out macros it's easy to use and produces beautiful documents with all the editing, revisioning and branching/merging advantages of plain text. –  Daniel Beck Jun 29 '11 at 18:20
@Adam That's what I meant with proper macros. The most unreadable stuff is the document "configuration" and you can "import" the actual document content into those, so your users never need to edit those. What's left is pretty much plain text with some formatting such as \section{This is a big title} and \emph{I want to emphasize this}. –  Daniel Beck Jun 30 '11 at 3:21
@Adam,@Daniel: Some plaintext markup toolsets will transform markdown-like markup into LaTeX (and thence into PDF etc). So you can have your cake and eat it - the simplicity of markdown, the elegance of LaTeX. multimarkdown supports tables. some of the other features (TOC, etc) can be added during processing. –  RedGrittyBrick Jun 30 '11 at 14:55
–  RedGrittyBrick Jun 30 '11 at 14:59

Could a system based on a Markdown (or something similar) and a VCS serve as a suitable replacement for MS Word in a large number of applications,

It depends on what counts as "large". There are clearly some situations where a plain-text markup system could replace MS Word.

Of course, you could use MS Word to author and edit your markdown text files! So the real choice is between .doc/.docx formats and markdown .txt format.

There is a kind of parallel with distraction-free editors.

while simultaneously providing additional critical functionality that is sorely lacking in the current tools?

For me, the key reasons for using something like markdown include

• future-proof (ability to read plain .txt should outlive ability to read Word-97 .Doc)
• simple (hence usable with small quick editors)
• separation of content from presentation.
• compact.
• portable (Linux, Mac, Tablets, Smartphones, Online)
• amenable to use with typical *nix text-oriented tools (grep,sed,awk,perl ...)

What critical features of word processors am I ignoring that this new approach could not replicate?

For some people, any of the following might be critical:

• WYSIWYG
• Tables
• Control over pagination
• Autospell

What would be the obstacles (both technical and cultural) to adoption of a radically new paradigm for generating documents?

• Inertia. Retraining.
• Support for more than one document-production system in an organisation.
• Inability to handle MS-Word documents originating outside the organisation.
• Concern about support from software maker.
-

Because of limitations of Markdown (it really wasn't designed for more serious documents than blog posts) I'd strongly advise anyone considering this kind of approach to check out Restructured Text. RST has a proven track record in very complex documents, can render to Tex (Latex/Xetex) and even include raw Tex data (pull it from external files even, to avoid "polluting" user edited documents). OTOH it's fairly similar to Markdown in it's syntax (it's a plaintext format that more/less uses standard ASCII formatting people used in txt documents like RFCs etc).

Unfortunately, while there are many distraction-free editing environments for RST (like ReText which also supports MD) there are no full-blown WYSWIG editors that render proper RST which might put off some users -- tho it could keep the tag-soup Word abusers that don't structure their documents but instead use direct formatting for everything fairly in line, as they would not have that liberty in their new editing environment.

Good thing about RST when it comes to tables is that it supports many definitions, from purely graphical ones like:

============================
| Key     | Value          |
============================
| 1       | Foo            |
| 2       | Bar            |
============================


to those based on formats such as nested lists or CSV like. It's also fairly extensible to meet the needs of multiple types of documents. I'd dare say that with a pretty WYSWIG editor and some nice web UI, could make a RST + GIT a great replacement for "big" EDMS systems.

-