Multiline annotations support

[crazyproger]

Hi! Is there support (or plans to add support) for multiline annotations in revdiff?
Currently, when pasting multiline text from clipboard into an annotation, all lines are merged into one.
It would be helpful to:

• Preserve line breaks when pasting from clipboard
• And/Or add a keyboard shortcut (e.g., Ctrl+Enter) to insert newlines manually while typing annotations

Would you consider adding this feature?
Thanks!

[umputun]

thx for the suggestion.

I'm trying to understand the use case better. you mentioned pasting multiline text from clipboard - could you describe what you're pasting and where it comes from? I don't quite get this flow, i.e. what kind of text do you copy from another app to paste into a revdiff annotation?

currently annotations are visually word-wrapped on screen regardless of line breaks, and the output consumed by AI agents treats the text the same way with or without explicit newlines. agents are the only consumer for those annotations in any workflow I can think of, and they don't care about formatting - just the content. so from a practical standpoint, pasted multiline text that gets flattened to a single line should still look and work the same.

is there a specific scenario where preserving line breaks actually matters - like structured lists, code snippets, or smth else? I'm trying to figure out the general use case here.

I did a quick estimate and this would require switching the input widget from single-line to multi-line textarea, updating rendering, output format, and key handling - roughly 400-500 lines of changes across several files. not huge, but still needs a good justification before adding that extra complexity.

[crazyproger]

In my case problems came up in two specific situations:

1. Significant plan corrections

When the AI takes a wrong turn and I need to explain what went wrong and why in detail, the annotation gets long. Lists are exactly what's missing here. I use them constantly when communicating with Claude, and revdiff feels like a natural extension of that workflow — so instinctively I try to write things like:

You're wrong here because:
1. you missed this
2. this part should work differently
3. add this and you'll get the right result

Sometimes a multi-line comment makes more sense on a single plan item rather than splitting it across multiple line annotations. That said, I acknowledge this might be personal style.

2. Clipboard pastes

Specifically: pasting a small slice of a DB table so the LLM can reason from actual data rather than from my description of it. In some cases, showing a few real rows is just more precise than explaining the schema in words.
For reference — in GitHub code review I use list-style comments frequently too. That's where the muscle memory comes from.

On implementation — what about $EDITOR instead of multiline textarea?
Would an $EDITOR-based approach be simpler? Here's the idea:

• User presses Ctrl+E → current annotation text (if any) opens in $EDITOR
• On save + exit, the annotation is applied. Ideally displayed with newlines preserved, but even flattened is acceptable
• If the user navigates to an existing multiline annotation and presses Enter, it reopens in $EDITOR directly

This sidesteps the need to rewrite the input widget, rendering, and key handling — the editor does the heavy lifting.

Current workaround I'm using: leave a "let's discuss this" marker annotation, submit the review, wait for Claude to return, then handle each flagged item in the Claude Code terminal with full multiline capability. It works, but costs one extra round trip with the LLM and breaks the flow.

One more thing I noticed: there seems to be a character limit on annotation length. At some point I simply couldn't type more. Not sure if that's intentional, but it adds to the friction when writing longer corrections. Is it intended or should I fill the issue about this?

[umputun]

re: limit

it had 500 chars limit for a single annotation (file or line level). changed both to 8k in 6395e6d

[crazyproger]

just made #113 (comment) and it seems that in many cases it is more comfortable than a native cc input form!

For this use case multiline annotations are also important.

[umputun]

see #115