### Problem The Rich Text Editor forgets all the formatting preferences of a Markdown file when saving changes. This is because the Content Editor re-generates the entire Markdown source from the Markdown API output instead of only generating Markdown for the parts of the file that were edited in the editor. ### Proposal We have to preserve the formatting preferences of the Markdown source that the user hasn’t edited in the Rich Text Editor. ### Approach More detail can be found in the [architecture proposal](https://docs.google.com/document/d/1aYfWIyavQAK_rJw23YMFZlPBRRAzTupXdGR0CUanmY4). ### Examples #### Avoid huge diffs In a long Markdown document, you might have 2500 lines of content. Let's say you prefer to write Markdown using asterisk for list items and number your ordered lists incrementally like `1. 2. 3.`. Now, you open the document in the Rich Text Editor and change a single word in a single paragraph. Because we rely on the backend parser, we know how to interpret each node and convert it to HTML for rendering the WYSIWYG representation of the data. But when we write that document back out to Markdown when you're done, we don't have enough information about what lines you changed and how you formatted the document. So we convert all the Markdown to our specified syntax choices (hyphens for list items, `1. 1. 1.` for ordered lists, and so on). The result is a page diff that changes nearly the entire document structure, all for a single word. This is what we want to avoid because even though the output is _correct_, it's not **useful**. Our approach would allow us to target only the change to the specific paragraph that was edited and the diff would include only that change. #### Preserve preferences If I prefer to write Markdown headers using a syntax like ```markdown This is a heading ======= ``` and I start editing a document, I don't expect the editor to change my file to use hashtag syntax. The resulting output would be ```markdown # This is a heading Here's my new content ``` which is not acceptable for those who painstakingly format their Markdown. Our approach avoids this conflict.