Potential Contributions: Pandoc ↔ Automerge, Pandoc ↔ ProseMirror, Diffing Trees based on Pandoc

[arisgk]

I am building a rich text editor for prose writing, which is integrated with Pandoc (the editor has a Haskell library which is used by an ElectronJS app via WASM). Some of the modules I am developing could be of interest to the wider Pandoc community, so I will list them here to see if it makes sense to either incorporate to Pandoc or gradually make them more independent from my editor so that they are as reusable as possible:

• Pandoc ↔ Automerge: Converts Automerge rich text to/from other formats, leveraging Pandoc.
• Pandoc ↔ ProseMirror. Converts ProseMirror to/from other formats, leveraging Pandoc. This is not yet an independent module because it is coupled with my editor's ProseMirror schema. But with some more work the ProseMirror schema mappings can become an argument. Combined with the work done for Pandoc and Wasm, this can be very important in building Pandoc-powered rich text editing experiences to the web.
• Diffing Pandoc-based rich text trees. This library depends on tree structures which are heavily based on Pandoc. It combines tree diffing with inline (Patience) diffing algorithms to produce patches between two Pandoc documents (minimal steps to transform one document to the other). I am consuming this in my editor to produce diffs in ProseMirror, but it can be used in theory to display the diffs in any format Pandoc supports, as long as one defines how are diffs displayed in the specified format, like I did with ProseMirror decorations. Diffing becomes rich-text aware (e.g. heading level changes or inline marks changes are defined using Haskell types and are not implicit from plain-text diffs).

Open to feedback and ideas regarding if any of the above would benefit the Pandoc community, and if yes, what's the best way to move forward.

[jgm]

Certainly, a library for diffing two Pandoc documents would be very useful. Depending on the dependency footprint, it might even make sense to make this a module of pandoc-types. Alternatively, it could be a separate library. I'd have to think about whether adding diffing to pandoc itself would make sense, but my first impression is yes, this would be extremely useful.

I don't know anything about automerge or prosemirror, so I don't have an informed opinion, but I'm interested in what others think.

[arisgk]

Ok, great! So the main dependencies currently are:

• tree-diff
• patience, which is used as soon as a difference is detected in inline nodes.

There is also a dependency to pandoc-tree, which is another small library I wrote. pandoc-tree doesn't have any dependencies worth mentioning. It could be included in the diffing library but I extracted it as a separate module because I am reusing it in ProseMirror conversion. I still haven't uploaded any of these to Hackage but can do so soon.

Something useful to move this forward would be to understand what would be a good way of expressing diffs in:

• Pandoc Haskell types
• A format like Markdown or HTML

I can also add some golden tests that convey how trees are diffed currently (using Data.Tree.drawTree).

Open to discussing next steps on this.

[jgm]

Unfortunately tree-diff has a large dependency footprint -- I think most of its dependencies are already dependencies of aeson, and hence of pandoc-types, but there are some that aren't (ansi-term).

I'm not sure there's any good general way to express AST diffs in "Pandoc Haskell types" (assuming you mean Block and Inline here, and not additional structures like the ones provided by tree-diff). The best approach would probably be to use Span and Div elements with special classes to mark insertions and deletions. One could then hook up e.g. the LaTeX or HTML writer to render these in a reasonable way (or use a filter). We do something like that to handle track-changes in Docx.

A "more correct" but more disruptive would require new AST elements.

[jgm]

As for Markdown, you can search the issue tracker and discussions (and the archive of pandoc-discuss) for discussions of Critic Markdown (e.g. #5430).

[arisgk]

The best approach would probably be to use Span and Div elements with special classes to mark insertions and deletions.

Ok, let me try this then and we can probably discuss again based on some test cases that make it concrete.

Regarding dependencies, we can leave it as a separate library for now (not make it part of Pandoc itself).

[massifrg]

I'm not sure there's any good general way to express AST diffs in "Pandoc Haskell types" (assuming you mean Block and Inline here, and not additional structures like the ones provided by tree-diff). The best approach would probably be to use Span and Div elements with special classes to mark insertions and deletions.

A "more correct" but more disruptive would require new AST elements.

It depends on the goal of the diff.
In my case it's about merging the work of many people on the same set of (versioned) documents, the way you do with code in git, but for documents. So it's important to visualize the differences well and have a comfortable way of doing merges, especially in conflicts' resolution.

For markdown documents, essentially line-based like code, you can use the same tools you use for code (the tool I prefer is meld.
But markdown covers the most of pandoc types, not the whole spec.

For complete coverage we have native, json and xml formats. In this case tree-sitter based tools seem better, like difftastic and mergiraf.
(The xml format is more compact and readable than native and json, but for now it's not resilient to different indentations).
BTW, tree-sitter supports Haskell (-> pandoc native), JSON and XML.

[tarleb]

Pinging @AntoLC and @lunika, who are involved with La Suite and who, I believe, are using software built on top of ProseMirror and AutoMerge. Also @StephanMeijer, who wrote some nice conversion tools in that and similar contexts. Would the things mentioned here help you with your projects?

[StephanMeijer]

CC @virgile-dev

[StephanMeijer]

Interesting stuff. I’m trying not to push my own open source projects too hard, but I’ve been chatting with @tarleb about running document conversion in the browser.

I’m currently building DocSpec (https://github.com/docspec/docspec), a document converter in roughly the same problem space as Pandoc, but focused on converting to/from ProseMirror-based editors like BlockNote and Tiptap.

Demo videos are here: https://github.com/docspec/talks/tree/main/FOSDEM2026

The current plan is to port the codebase from Elixir to Rust, so it can compile to targets that run basically anywhere: FFI, WASM, HTTP API, AMQP workers, and CLI. I’m in the process of getting that work funded.

A first version is already integrated into La Suite Numérique (https://github.com/suitenumerique/docs), which uses BlockNote (Tiptap/ProseMirror-based; and they use Yjs for collaboration).

One of the core challenges with ProseMirror/Tiptap is that the schema isn’t fixed: users can enable/define their own node/mark types, so "supported elements" are inherently editor-specific. My current direction (that is yet to be implemented) is an extensible approach:

• Safe defaults by degrading unknown content types to plain paragraphs/text (no hard failure).
• Pluggable mapping through simple, ergonomic hooks that map custom node/mark types into explicit AST nodes in my converter.

I haven’t finalized the design yet, I’m intentionally waiting until funding is in place, because this is the hard part to get right.

Net-net: I think I’m in the same conversion space as Pandoc, and I’d love to see first-class support for web-based editors in Pandoc (or any other converter for that matter), especially the ProseMirror ecosystem, that would be genuinely huge.

Let me know if anyone would like to have a digital ☕ coffee about this subject, as it is something I am fairly passionate about.

[yanntrividic]

Update: the time slot we collectively picked is next Monday (16 Feb) at 2pm CET. If anybody wants to join, feel free to say so! (Ping @virgile-dev, just in case; we will be there with Camille and Michel.)

[virgile-dev]

@yanntrividic I'll try to make it. Which Camille are we talking about ? The one from DINUM ?

[yanntrividic]

My colleague that I think you met in Rennes last week with me and Michel, who works on OnePub!

[virgile-dev]

Ping @sampaccoud you're going to love this

[msakrejda]

I don't think I can make that time slot, but the way Automerge handles this problem may be relevant: basically, the document conversion takes a schema adapter. The adapters are a little complicated, but there is a default one that likely serves most users' needs. I wonder if these converters could benefit from the same approach?

[denismaier]

Maybe also @massifrg Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Albert Krewinkel ***@***.***> Sent: Friday, February 6, 2026 9:46:49 PM To: jgm/pandoc ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [jgm/pandoc] Potential Contributions: Pandoc ↔ Automerge, Pandoc ↔ ProseMirror, Diffing Trees based on Pandoc (Discussion #11443) Pinging @AntoLC<https://github.com/AntoLC> and @lunika<https://github.com/lunika>, who are involved with La Suite<https://lasuite.numerique.gouv.fr/produits/docs> and who, I believe, are using software built on top of ProseMirror and AutoMerge. Also @StephanMeijer<https://github.com/StephanMeijer>, who wrote some nice conversion tools in that and similar contexts. Would the things mentioned here help you with your projects? — Reply to this email directly, view it on GitHub<#11443 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABDTWJVSXR5AB337P5H2ICL4KT4TTAVCNFSM6AAAAACUCETBB6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNZSGI2TOOI>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[msakrejda]

I agree it'd be great to have built-in Automerge and ProseMirror support. In the context of pandoc, one can think of Automerge's rich text format as very similar to ProseMirror's format, and the latter seems like a natural fit for pandoc's purpose.