Repository navigation
Markdown files from external editors lose formatting on save #593
Description
Activity
Second that!
EDIT: Just found another extremely problematic behaviour: Automatic escaping of footnotes. Also not specified in CommonMark, of course, but it should not simply escape the square brackets, because it fully breaks support in those third-party editors that support those (besides, having links defined in-text and then the link at the bottom is in fact common, which uses exactly the same format)
Reacted by Benjamin Melançon, ainola, nilsbecker, Thomas Schmidt, Galen Rutledge, Ell (Julian), SandRock, Tobi Schäfer, Alexander Dunkel, Yichung Hsu and 6 more- changed the title
[-]Markdown files lose formatting on save[/-][+]Markdown files from external editors lose formatting on save[/+]on Feb 6, 2020 We use pico cms Nextcloud-Integration and need to be able to edit those .md files via Nextcloud.
However, this bug effects the ability to edit pico files, f.e. _meta.md looses all it's formatting and since it has a yaml header, it destroys parts of the website.
This is especially annoying, since there is no possibility to use the markdown editor or any other editor anymore in NC 18...Reacted by nilsbecker, everlanes, Andreas Haubold and R. W.May I suggest that, while WYSIWYG in Markdown is cool to have, a plain code view would be the easiest solution for the meantime until the mode works for everyone, so that we can work with the files easily without fearing to lose any data?
As the plain view was already implemented, it shouldn't prove too difficult to re-enable that and simply offer people a switch between the two!
Reacted by Jonathan, Sandra Groth, Benjamin Melançon, Georg Hake, ainola, FrViPofm, wintaeh, Thomas Schmidt, b12f, dumblob and 13 moreI've been having this issue as well. It disheartens me that we are now at NC19 and this still hasn't been addressed. The pico CMS is huge as it breaks the YAML code on the file.
This seems to be a pretty prominent and relevant issue. Since this (and duplicates) have been in a limbo state for some time now, I'll ping some people (maybe you also know other people to ping who could help out or are responsible for this application).
Reacted by nilsbecker, Stefan Gofferje, Danir Toma, SandRock, Tobi Schäfer and wintaeh111 remaining items
@max-nextcloud This issue still exists for me, at least for the android app. Any updates? Noticed it because I was syncing my Logseq notes through nextlcoud like @palmergw
I think two issues might be mixed here.
Did you edit your logs in text? If you do this this issue would still affect you.
If you just looked at the file there are no changes to persist and thus the file should not get saved. However we had a bug that triggered saves if no changes were made when closing the file. This has been fixed in 26.0.4 and 27.0.1. So if the files changed by just opening them - could you check if that still is the case for you on the latest versions?
@max-nextcloud This issue still exists for me, at least for the android app. Any updates? Noticed it because I was syncing my Logseq notes through nextlcoud like @palmergw
I think two issues might be mixed here.
Did you edit your logs in text? If you do this this issue would still affect you.
If you just looked at the file there are no changes to persist and thus the file should not get saved. However we had a bug that triggered saves if no changes were made when closing the file. This has been fixed in 26.0.4 and 27.0.1. So if the files changed by just opening them - could you check if that still is the case for you on the latest versions?
I switched to logseq built in syncing since issues like these were to much of a hussle. So as of now I cannot test this.
- moved this from 🧭 Planning evaluation / ideas to 🏗️ At engineering in 🖍 Design team
on Oct 17, 2024 Thanks for everyone reporting, contributing to the discussion in here and providing detailed examples and context regarding markdown formatting loss.
To summarize this a bit, the text app can currently change formatting beyond the edited lines—affecting whitespace, list markers, and other layout details—which breaks compatibility with external editors. The expectation is that edits should only affect what was changed, and unsupported or unrelated formatting should be preserved.
There are a few technical reasons we can’t “just stick to plain Markdown” in the collaborative editor:
- Under the hood, the editor uses tiptap (ProseMirror) with Yjs to synchronize a structured document model (nodes, marks, attributes), not serialized Markdown text. Collaboration features (cursors, selections, undo/redo, plugins) rely on this stable structure.
- Markdown text has many equivalent serializations (e.g.,
-vs*for lists, different indentation/blank lines). Re-serializing and reparsing is not identity-preserving and small text changes can reshape large parts of the document. With concurrent edits, that can invalidate other users’ selections or operations (e.g., removing a leading list marker could collapse a nested list mid-edit).
What we’re doing:
- Reduce normalization and minimize unrelated changes on save
- Preserve common authoring choices where feasible (e.g., list markers and numbering, indentation/blank lines, soft vs. hard breaks, code block fences)
- Add targeted tests to prevent regressions and limit normalization to affected ranges where possible
How we’ll track this:
- We will handle specific formatting inconsistencies as separate, focused issues. This helps us diagnose and fix each case precisely.
- If you encounter a concrete mismatch, please open or comment on a dedicated issue with a minimal “before → after” example (and editor/environment details).
Closing this umbrella ticket to avoid duplication. Ongoing work to reduce formatting changes on save will continue to be tracked in individual issues. Your feedback has been noted and is helping guide these improvements, so I'd kindly ask anyone that encounters specific changes happening to report them with concrete examples through our issue template for those cases https://github.com/nextcloud/text/issues/new?template=Markdown.md
Reacted by Juan Miguel Serrano Rodríguez, Daniel Scharon and Jan C. Borchardt- moved this from 🏗️ At engineering to 🎉 Done in 🖍 Design team
on Nov 19, 2025
Summary
Markdown files that are created in external markdown and text apps will have their formatting completely overridden and/or lost when edited through the Nextcloud web interface. Newlines, tabs, and spaces are thrown out everywhere in the document--not just on the edited line--and lists will be changed to asterisks instead of dashes. See screenshots below.
Background
I use external text editors for my markdown files and then sync them to my Nexctloud. I primarly use Atom for its markdown support but will also use basic text editors like Gedit on Linux or Notepad on Windows. That's the great thing about markdown files, after all, they're just plain text. When I edit these files through my Nextcloud web interface, the formatting of the entire file is destroyed.
Related: #390
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I expect the Text app to not completely destroy any formatting created by external apps. If any special formatting is unsupported, it should be left alone for maximum compatibility with external apps. If any formatting changes must be made based on the current edits, those changes should apply ONLY to the current edits and not the entire file.
Screenshots
How it looks in Gedit under Linux:
How it looks when opened in my Nextcloud web interface:
Make an edit through the web interface and now the file's formatting has been destroyed when viewed in Gedit:
Client details:
Server details
Text app version: 1.1.1
Operating system: Ubuntu 18.04.3
Web server: Apache
Database: Mysql 5.7.29
PHP version: 7.3.13
Nextcloud version: 17.0.2