` HTML tag.\n- Group: `block`\n- Content: `inline*`\n- `config.buttonEnabled` must be `true` to enable this node.\n\n\n### `code_block`\n\n- A block-level node representing a block of preformatted code.\n- Attributes:\n - `language`: The programming language of the code block (optional).\n - `annotations`: An array of annotations for the code block (optional).\n - `name`: Filename associated with the code block (optional).\n- Parsed from `
` HTML tags.\n- Group: `block`\n- Content: `text*`\n\n### `custom_html`\n\n- A block-level node representing custom HTML content.\n- Attributes:\n- Content: `text*`\n\n\n## Marks\n\nThe following marks are supported:\n\n- `code`\n\n- `link` (attributes: `href`)\n- `em`\n- `strong`\n- `strike`\n- `sup`\n- `sub`\n- `suggestion` (attributes: `type`, `id`, `add`, `remove`) - see [Suggestions & Comments](#suggestions--comments) below. Not meant to be toggled directly; use the suggestions plugin's commands instead.\n\n\n## Suggestions & Comments\n\nTrack-changes (suggested insertions/deletions/formatting) and comment threads share one\nmark (`suggestion`) and one node attribute (`suggestions`), so they're set up together via\na single plugin.\n\n```svelte\n\n\n\n```\n\n### Attribution: `author` and `resolveAuthor`\n\n- `author` is the id of whoever is currently editing (`` `user:${string}` `` or `\"ai\"`), attached to\n every suggestion/comment this session creates.\n- `resolveAuthor(author)` turns an `Author` id into `{ name, picture? }` for display in the\n floating review panel. May be async (e.g. a network/directory lookup).\n\n### `source`: where authorship and comment content actually live\n\n**Author identity and comment/reply content are never stored in the document itself** -\nonly a mark/node-attr `id` is. This is deliberate: the document is fully client-editable\ncontent, so embedding `author` in it would let anyone claim any author by hand-editing the\nsaved JSON. Instead, `source` is a host-supplied backing store the plugin reads/writes by\n`id` - the same \"editor only holds a reference, host owns the real data\" pattern as\n`editorConfig.fileUploader`. Real authorship enforcement (e.g. stamping the authenticated\nuser server-side, rather than trusting whatever a client passes into `create`/`reply`) is\nthe host's responsibility, not the editor's.\n\n```ts\nimport type { SuggestionSource } from '@hyvor/richtext';\n\nconst source: SuggestionSource = {\n // Called in batches whenever the editor encounters ids it hasn't seen yet\n // (e.g. right after loading a document). Return null for an id your\n // backend has no record of - it will not be retried.\n async get(ids) {\n const rows = await api.getSuggestions(ids);\n return Object.fromEntries(ids.map((id) => [id, rows[id] ?? null]));\n },\n\n // Fire-and-forget notifications - called once per event, after the\n // causing change has already been applied locally.\n create(id, type, author) {\n api.createSuggestion({ id, type, author });\n },\n reply(id, reply) {\n api.addReply(id, reply); // reply: { id, author, content, timestamp }\n },\n resolve(id, decision) {\n // decision: \"accept\" | \"reject\" | \"resolve\"\n api.resolveSuggestion(id, decision);\n },\n};\n```\n\n`get`/`create`/`reply` are required; `resolve` is optional (skip it if you don't need to\nclean up resolved/accepted/rejected records host-side).\n\n### Commands (from `@hyvor/richtext`)\n\n- `getSuggestions(state)` - list all pending suggestions/comments (`{id, type, author,\n from, to, comments, ...}`); `author`/`comments` are `null`/`[]` until `source.get`\n resolves them.\n- `acceptSuggestion(view, id)` / `rejectSuggestion(view, id)` - resolve a single\n insert/delete/format suggestion.\n- `acceptAllSuggestions(view)` / `rejectAllSuggestions(view)` - bulk variants (skip\n comment-type entries).\n- `addComment(view, text)` - attach a new comment thread to the current selection.\n- `replyToSuggestion(view, id, text)` - reply to any thread (a comment, or a live\n suggestion) - this never touches the document, only `source`.\n- `resolveComment(view, id)` - close a comment thread.\n- `setSuggestionMode(view, mode)` / `getSuggestionMode(state)` - toggle `'editing'` vs\n `'suggesting'`; while suggesting, edits are recorded as suggestions instead of applied\n directly.\n- `setCurrentAuthor(view, author)` / `getCurrentAuthor(state)`.\n- `seedSuggestionSource(view, entries)` - pre-populate the plugin's local cache with\n already-known `{id, type, author}` triples without waiting on `source.get()` - useful\n for suggestions your app generates itself (e.g. `buildDiffDoc`'s output, see below)\n rather than ones the user typed.\n\n### Diff view\n\n`buildDiffDoc(diffs, schema)` (from `diffDoc`'s output) builds a suggestion-annotated\ndocument from a two-document diff, for a track-changes-style merged view. It returns\n`{ doc, suggestions }` - `suggestions` is the list of generated `{id, type}` pairs, which\nhave no author of their own (a diff has no per-change authorship) and must be attributed\nby the caller, typically via `seedSuggestionSource` or by writing directly into your\n`source`'s backing store.\n\n\n## Collaboration\n\nReal-time collaborative editing is built on [`prosemirror-collab`](https://prosemirror.net/docs/ref/#collab).\nThe editor never talks to a server itself - the host provides a transport via\n`editorConfig.collab` and feeds remote steps back in via `editor.collab.receiveSteps()`.\nServer-side implementation (assigning versions, rebroadcasting steps to other clients,\npersisting the document) is entirely up to the host app.\n\n```svelte\n\n\n\n```\n\nWhenever your transport receives a batch of steps from the server (including batches made\nup of this client's own steps being confirmed), pass them to:\n\n```ts\neditor.collab.receiveSteps(steps, clientIDs);\n```\n\n`editor.collab.getVersion()` returns the editor's current collab version.\n\nSee `DEV.md` for a minimal local WebSocket server used to try this out during development.\n\n### Cursors (other users' selections)\n\nShows other users' cursors/selections as a colored caret + tinted selection, with a name\ntooltip on hovering the caret. Same split as collaboration: the editor never talks to a\nserver - the host provides `editorConfig.cursors` and feeds remote cursors in via\n`editor.cursors.set()`.\n\n```svelte\n\n\n\n```\n\nWhenever your transport tells you about other users' cursors, pass the full current list to:\n\n```ts\neditor.cursors.set(cursors); // RemoteCursor[]: { clientId, from, to, user: { name, color, picture? } }\n```\n\n`clientId` identifies which user a given entry belongs to across updates - reusing\n`editorConfig.collab`'s `clientID` is the natural choice if you're running both together.\n`user.color` is any CSS color, used for the caret, tooltip, and (tinted) selection\nhighlight.\n\nSee `DEV.md` for how the local WebSocket server also relays cursor presence.","readmeFilename":"README.md"}