Raw markdown editing

[timotoots]

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:

occ config:app:set text rich_editing_enabled --value=0

[mejo-]

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 :thinking:

[mejo-]

There's #123, #323 and #815, all closed. Shall we keep this issue open or re-open one of the earlier ones? @max-nextcloud @juliushaertl

[datenangebot]

I 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.

[juliusknorr]

Yes, 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 https://github.com/nextcloud/text/issues/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)

[l-mb]

I see the issue if editing in collaborative mode. However, this would still be really useful.

To start with, even obtaining an exclusive lock when raw mode 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.

[JL710]

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.

[juliusknorr]

Either 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.

[n8falke]

I see why a good solution is complicated to implement.

Is it easier to implement a way to copy markdown-source to the clipboard?

[JL710]

@n8falke you can simply mark the section you want to copy and press control+c. That copies it to the clipboard. Then you can simply paste it into notepad or something like that.

[n8falke]

@JL710 control+c only copies the text and HTML version.

The Idea was to get the markdown, i.e. to be used here, in a README.md or to edit it, copy and paste it back, to fix errors like described above.

[JL710]

@n8falke when I paste the copied text into any normal text input, browser or local text editor, I get the raw markdown. With headings marked as with hashtags etc.

[n8falke]

@JL710 you are right if you use the headings, tables, lists, multi-line-source-code. Thanks for the hint that can help.

I tested with bold text. Which is lost. Same seems to be with italic, code etc. Pasting into NC seems to work.

[borgdrone7]

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

[tewe]

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.

[max-nextcloud]

@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?

[max-nextcloud]

@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.

[borgdrone7]

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!

[max-nextcloud]

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.

[borgdrone7]

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.

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!

[githubbbie]

This is very important feature for modern workflows. AGREE

[juliusknorr]

@githubbbie Please use the 👍 reaction on the first post instead of commenting like that, this does not add any value to the discussion.