### Problem to solve <!-- What problem do we solve? --> We have a rich markdown editor in at least 6 places: MR editor, MR notes, issue editor, issue notes, wiki editor, and milestone editor. The first 4 are somewhat Vue-enabled, while the last two are pure jQuery. There is some code being duplicated in all 6 places. Further, we implement rich editing logic for this editor from scratch. Formatting buttons are custom, zen mode is custom, and we will soon have [custom indentation, shortcut keys, and undo behaviour](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/28914) in it as well. The markdown editor is a `<textarea>` that is becoming increasingly bloated with more and more features nailed onto it. Given that the markdown editor is a very important component, I propose that we move it to a third-party editor like [Codemirror](https://codemirror.net/mode/htmlmixed/index.html) or [Ace](https://ace.c9.io/). From a brief investigation, Codemirror looks better. We use the [Monaco](https://microsoft.github.io/monaco-editor/) editor elsewhere, but Monaco is not compatible with mobile platforms. Failing that, we should make a re-usable component out of GLForm with an easy-to-use editing API, so that we can extend it easily. Unless we can find an editor that is sufficiently lightweight and provides what we already have out-of-the-box, this may be the better solution. My worry is that if we continue to add more and more features to the markdown editor, it will devolve into a bloated, unmaintainable mess that will be hard to change down the road. @winh @donaldcook Who else might be interested in this? Is this worth pursuing? ### Intended users Developers, testers, QA, documentation/technical writers, product managers, end users. ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? --> ### Documentation A rich text editing component would deserve its own doc page that outlines all the features we support (indentation, markdown editing, autocomplete, commands, etc.) ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ --> Will require cross-browser testing, as well as refactoring of all tests that touch the markdown editor. ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> - Better code quality - Higher velocity for this particular component - Fewer abandoned issues/MRs ### Links / references