feat: inline comments

[mejo-]

📝 Summary

This PR implement inline point-anchor comments as discussed in #185.

• Comments can be inserted via toolbar submenu, by typing [?] or by pressing Ctrl-Alt-M
• A superscript chat bubble icon (💬) marks the comment anchor in the text. Clicking it opens the comment bubble
• Inside the comment bubble, one can add, edit and remove replies
• Comments and footnotes can be hidden to improve legibility via "Hide annotations" in the toolbar submenu
• Resolves: Inline comments #185

Markdown representation

Comments are stored using the footnote syntax already supported by Text, with a comment- prefix to distinguish them from regular footnotes:

The quick[^comment-1] brown fox.

[^comment-1]:
    - @[jane](mention://user/jane) *(2026-05-21T10:30Z)*
      Is "quick" the right word here?
    - @[bob](mention://user/bob) *(2026-05-21T12:45Z)*
      I think "fast" is more accurate.

Existing Markdown editors with footnote support (Obsidian, Ghostwriter) render the comment definitions as footnotes and make them accessible.

🖼️ Screenshots

Toolbar submenu	Comment bubble	Entering first comment reply	Editing a reply

🖼️ Screencast

🚧 TODO

• Regression: Undo is now always disabled in toolbar
• Would be great if adding/editing/deleting replies could be undoable as well edit: turns out it already is 🎉
• Support to mention users in comments
• Optionally replace NcRichContenteditable with a stripped-down Text editor for editing comments and replies

🏁 Checklist

• Code is properly formatted (npm run lint / npm run stylelint / composer run cs:check)
• Sign-off message is added to all commits
• Tests (unit, integration and/or end-to-end) passing and the changes are covered with tests
• Documentation (README or documentation) has been updated or is not required

🤖 AI (if applicable)

• The content of this PR was partly generated using AI tools
• The AI-generated content was reviewed, comprehended and tested by a human

[silverkszlo]

When being a guest, I can not edit previous comments before I enter a guestname, but I can delete them. Is that intentional?

[mejo-]

the two close-icons get very close to each other, when there is multiple comments

Good catch. I fixed this by switching to placement: 'left-start' for the floating-ui bubble. It's cleaner anyway in my opinion.

Adding a very long comment breaks it and one also can not scroll down inside the comment bubble anymore. Maybe it would make sense to set a max number for characters?

Another good catch. Fixed by setting a max-height for the multiline input field.

When being a guest, I can not edit previous comments before I enter a guestname, but I can delete them. Is that intentional?

Indeed, that's inconsistent. I changed this now that deleting is only possible after adding a guest name as well for consistent UX.

I also did the following:

• Visually highlight the reference of the currently open comment bubble.
• Add navigation buttons to comment bubble to jump to previous/next comment.
• Improve keyboard navigation:
  • allow to navigate to references via tab
  • open comment bubble on Enter/Space
  • close comment bubble on Esc
  • place cursor in editor content after reference after closing comment bubble via Esc or button

[jancborchardt]

Very cool! Some first feedback:

• Showing/hiding annotations changes the text flow a little bit, which makes things look unstable/brittle. That might be because the comment emoji is aligned a bit to the top? It’s fine if it’s vertically centered, it would be more important for the text not to move vertically. :)
• The comment field is quite large / high, which makes it a bit massive and imposing. It would be ok to reduce it to the height of 3.5 lines of text, or even a single line if we use autosize.
• The "Edit comment" and "Delete comment" actions can go into a 3-dot action menu. Then they can have proper text and are not so in-your-face.
• A quick animation moving the comment field down when sending the comment would be nice. Better than an interface jump
• Right now it is only possible to show a single comment thread, right? Other solutions make it possible to view all comments at the same time, which is especially useful if there are multiple and not really many replies going on.

[mejo-]

Right now it is only possible to show a single comment thread, right? Other solutions make it possible to view all comments at the same time, which is especially useful if there are multiple and not really many replies going on.

I would like to keep this for a follow-up, as I have to say I find it quite confusing how others display all the comments per default and I think we should think this through properly.

All other comments addressed @jancborchardt ☺️

[max-nextcloud]

minor nitpick:
I don't like this annotation specific logic in the generic menu handler.

I think the check could be moved into the action function of both footnote and comment buttons. But then I am not sure if it wouldn't be better to make annotationsHidden a part of the editor itself. That way one could also prevent creating annotations with keyboard shortcuts, when they are hidden.

[mejo-]

I agree and I had a similar sentiment regarding where to track the state of hiding annotations. I moved this to a dedicated editor extension now. It was not an easy one, but I think I found a good solution. Curious what you think: 77bfff6

[mejo-]

@mejo- thanks! :) Of course fine to have it in a follow-up. But I’d say it’s definitely very important, as long comment-threads are not something very common. And if you have to go through a lot of small feedback / grammar fixes in one document, it gets cumbersome if you have to manually select the comments.

@jancborchardt in general I agree. Just a short addition: there's navigation buttons to navigate to previous/next comment in the comments bubble, that should help a bit with it.

[jancborchardt]

@mejo- yeah I did see those – that's still manual work though (and needs expecting and then finding them first as well). :) Anyway, smth for a follow-up as you said.

[max-nextcloud]

Ah... I see, you still need to loop through the doc descendants to get the commentPos. I thought we could do away with the entire loop here as we already loop through it when getting commentNode in the BubbleView.

[max-nextcloud]

Had a look at all commits. Looks good to me.

[ntnsndr]

This is so exciting, thank you!