Repository navigation
Raw markdown editing #3570
Description
Activity
Thanks for your report @timotoots.
I'm pretty sure that there is already an issue for tracking this feature, but I failed to find it now when searching for it 🤔
Reacted by githubbbieThere's #123, #323 and #815, all closed. Shall we keep this issue open or re-open one of the earlier ones? @max-nextcloud @juliushaertl
Reacted by Edges and githubbbieI can not find a way to see and edit the raw file content within the editor. So we keep this issue open as feature request.
Reacted by githubbbieYes, this is not implemented yet. A few thoughts as I think it might make sense to have this at some point, however it is not on our roadmap so far. Contributions for this would of course be very welcome.
- We'd need a toggle for a preview next to the raw editor (also related to AsciiDoc support #3564)
- We would need to limit the full editing session to either raw or rich text editing since otherwise the rich editor may change the content in an unexpected way if some users join with rich editing
- Some open questions:
- Would this be a user or per document setting?
- What happens if a user prefers plain markdown but the document is currently opened by another user in rich text mode (or the other way round)
Reacted by Scott Idem and githubbbieI see the issue if editing in collaborative mode. However, this would still be really useful.
To start with, even obtaining an exclusive lock when
rawmode is activated by someone would be useful for repairing broken Markdown or inspecting what's going on. One can do it right now anyway (by opening the file in a synced directory), so having it in the web mode would just be more convenient.The technical reasoning with collaborative editing sounds reasonable.
Wouldn't it be possible for the administrator to decide on a view (Or on a User or File Level)?
It could be a setting that the author of a file needs to decide when sharing a file.Reacted by Patrick KranzEither on an instance wide admin defined level or file level would work, per user not as you could then have two users with different settings open the same file.
Reacted by tewe and Patrick KranzI see why a good solution is complicated to implement.
Is it easier to implement a way to copy markdown-source to the clipboard?
3 remaining items
Why WYSIWYG-only editing is critically limiting in 2025
I want to emphasize how important raw Markdown editing capability is for Collectives, especially in the current AI/LLM era. The lack of this feature significantly limits the app's usability in modern workflows.
The fundamental problem:
Collectives stores content as Markdown files (.md) but only allows WYSIWYG editing in the web interface. This creates a major friction point for modern knowledge work.
Why this is problematic:
- AI/LLM Integration: Large language models (ChatGPT, Claude, etc.) output Markdown natively. When an AI generates documentation, technical specs, or meeting notes in Markdown, there's no way to paste it into Collectives and have it render
correctly. The raw Markdown syntax appears as literal text, making AI-assisted documentation workflows nearly impossible. - Developer-First Workflows: Technical teams think and write in Markdown. Forcing them through a WYSIWYG interface adds unnecessary friction. Many developers have Markdown muscle memory (## Heading, bold,
code) and typing these patterns is
faster than clicking toolbar buttons. - Content Portability: Markdown is the universal format for technical documentation. Content from GitHub, GitLab, Confluence, Notion, Obsidian, etc. is often in Markdown. Without raw editing, moving content into Collectives requires manual
reformatting through the WYSIWYG interface. - Automation & Scripting: Modern teams automate documentation. Scripts can generate Markdown reports, API docs, or meeting summaries. These can't be directly imported into Collectives because there's no programmatic way to work with the content
in its native format. - Version Control Integration: While Collectives files can theoretically be version-controlled (they're .md files), editing must happen through the web interface. Teams can't efficiently use their existing Git workflows with their preferred
Markdown editors. - Markdown IS the source of truth: It's ironic that Collectives stores everything as Markdown but hides this from users. The format is already there - we just need the ability to see and edit it directly.
Current workarounds are insufficient:
- Editing via Files app adds too many steps (navigate to folder, find file, open in Text app)
- External editors require syncing and break the collaborative real-time aspect
- The WYSIWYG editor doesn't support all Markdown features, making round-tripping impossible
What we need:
A simple toggle or keyboard shortcut to switch between WYSIWYG and raw Markdown view within the Collectives editor. This is standard in modern tools:
- Notion has this
- GitLab has this
- GitHub has this
- Obsidian has this
- Typora has this
Impact on adoption:
For teams evaluating Collectives as their knowledge base, this limitation is often a dealbreaker. The app has excellent collaborative features, but the editing experience doesn't match how technical teams actually work in 2025.
In the age of AI-assisted work, the ability to seamlessly integrate LLM-generated content is not a nice-to-have - it's essential for productivity. Without raw Markdown editing, Collectives is fighting against the direction the entire knowledge
management ecosystem is moving.Reacted by mr-gosh and hlovdalReacted by sokai, githubbbie and mr-gosh- AI/LLM Integration: Large language models (ChatGPT, Claude, etc.) output Markdown natively. When an AI generates documentation, technical specs, or meeting notes in Markdown, there's no way to paste it into Collectives and have it render
In case anybody else is as confused as I was: Collectives is a different app with its own issue tracker. But it embeds the Text app, so the comment above is not wrong here.
@borgdrone7 I just tried and Nextcloud Assistant inserts markdown just fine. My query was:
Create a basic grocery list with 5 list items and a heading in markdown format
The result was:
To my understanding Nextcloud Assistant can be integrated with various AI backends.
When I copy and paste that result into a plaintext text editor the result is markdown. Copy and pasting the plaintext markdown into Collectives renders it as markdown again.
Could you explain your concrete workflow? Which OS and browser are you using, what are you copying from and where are you copying it to?
@n8falke We had to come up with a heuristic here as people were complaining about strange characters when copying text from the text editor.
In particular when pasting into all kinds of forms - browser urls, address forms, bank account etc you would not expect extra characters to be added just because part of the source is bold or italic. These forms also expect plain text so they used to trigger markdown conversion.
If I remember correctly we tried to only add markdown syntax when copying multiple nodes (such as a heading and a list) and only keep the markdown for document structure - not text formatting to avoid confusing people who are not familiar with markdown.
Could you explain your concrete workflow? Which OS and browser are you using, what are you copying from and where are you copying it to?
Thanks for testing! Copy/paste does work for simple cases.
My workflow is different though - I work iteratively over long sessions with CLI AI agents that have codebase access. I make dozens of incremental edits, and copy/pasting each time becomes impractical.
I may be in the minority, but I find editing raw Markdown much easier than WYSIWYG, while viewing is better in WYSIWYG (especially for complex docs). Mermaid diagrams already have a "source code" option - something similar for the whole document would be perfect.
Quick question on the collaborative concern: since both views render the same Markdown source, what specific sync issues would occur? Genuinely curious about the technical challenge.
Thanks for the great work on this project!
Quick question on the collaborative concern: since both views render the same Markdown source, what specific sync issues would occur? Genuinely curious about the technical challenge.
Under the hood we use tiptap which uses yjs to synchronize editing sessions. However it synchronizes the data structure of the editor - not the serialized markdown. Now some changes to the source code can change large parts of the document structure. We're pretty sure that will break editing for others in funny ways. Imagine you're writing somewhere in a nested list - but out of the sudden it's not a list anymore at all because a leading
*was removed. Where should your edit go?But to be frank I have not tried combining the two modes yet.
Reacted by githubbbieUnder the hood we use tiptap which uses yjs to synchronize editing sessions. However it synchronizes the data structure of the editor - not the serialized markdown. Now some changes to the source code can change large parts of the document structure. We're pretty sure that will break editing for others in funny ways. Imagine you're writing somewhere in a nested list - but out of the sudden it's not a list anymore at all because a leading
*was removed. Where should your edit go?But to be frank I have not tried combining the two modes yet.
Thanks for the detailed explanation! That makes sense, the cursor mapping and parsing edge cases during typing would definitely add complexity.
A simpler approach might be to only enable raw markdown editing when there are no active collaborators, keeping it disabled in collaborative sessions. That way it avoids the sync challenges while still providing the feature for solo editing.Appreciate you taking the time to explain the technical constraints!
Reacted by githubbbie and Antonello Lobianco@githubbbie Please use the 👍 reaction on the first post instead of commenting like that, this does not add any value to the discussion.
Reacted by Patrick Kranz, sokai, Nicolas Lenz and hex-m- added a commit that references this issue
on Jul 22, 2026 Hi! 👋 I made a pull request to solve this issue last night. This is my first time contributing to Nextcloud, so I would appreciate if the maintainers can tell me if I did anything wrong.
Reacted by sokai, msm-cert and KapisI think it would be great if we could also have collaborative editing on raw markdown (e.g., like HedgeDoc). This is something the PR from @soapergem wouldn't allow iiuc.
Would something like this be feasible: as long as there is only a single user editing a file, they can freely switch between raw and rich editing. Once more users join, the file would "lock" in its current editing mode for all users. Maybe we could still allow the first user to switch the mode for all users?
the 'Edit raw' button quietly depends on what your source of truth is. if Text stores a parsed prosemirror doc and not the file bytes, the raw view gets serialized back FROM that model, so the non-standard element that rendered wrong already got normalized before you ever toggle. you'd be editing the editor's markdown, not the markdown you actually wrote. it's only a real fix if raw is the canonical store and the rich view renders off of it, not the other way round. otherwise the toggle round-trips you through the same normalizer that mangled it in the first place.
Is your feature request related to a problem? Please describe.
Sometimes markdown has non-standard elements that Text renders as it thinks is standard.
Describe the solution you'd like
A button "Edit raw" that would allow editing raw markdown.
Describe alternatives you've considered
Additional context
If you always want to edit raw markdown on your instance you can disable the richtext rendering and editing with this command: