Same view, multiple cursors?

[decentral1se]

Thanks for all the work, v2 is rad!

Are multiple cursors on a single view possible? I'm playing around with multiplayer editing of text.

I realise now that on the same view, only a single cursor is possible with the current API.

v := tea.NewView("foo")
v.Cursor = tea.NewCursor(x, y)

Ref: https://sw.kovidgoyal.net/kitty/multiple-cursors-protocol/

[GautamKumarOffical]

Good question! You are right that the current Bubble Tea API only supports a single cursor per view through CursorMode and the Cursor field in the model.

For multiplayer text editing with multiple cursors, here are a few approaches:

1. View composition - Render each cursor as a separate visual layer. You can overlay multiple cursor positions by computing the absolute screen position for each remote cursor and rendering them as part of your View() output (using ANSI escape sequences or Unicode block characters).

2. Custom rendering - Since Bubble Tea gives you full control over the terminal output in View(), you can manually place cursor markers at multiple positions. The Kitty multiple cursors protocol you linked is terminal-dependent and not widely supported yet.

3. Programmatic cursor - Use tea.SetCursorAt(x, y) in a Cmd to move the hardware cursor, and render visual markers for other cursors as part of your view string. This way the hardware cursor follows one user while other cursors are drawn as overlays.

The Loro integration you mentioned is interesting - for the data layer, Loro handles the CRDT sync. On the rendering side, Bubble Tea would need to render multiple visual cursors as part of the view rather than relying on the single hardware cursor.

This could be a good feature request issue if you want to propose adding multi-cursor support to the View API.

[truffle-dev]

I built multi-cursor editing on top of Bubble Tea v2 in a terminal editor (nook), so here is the shape that actually worked, building on what @GautamKumarOffical said.

The load-bearing decision is that there is exactly one hardware cursor and you give it to one caret only: the local user's. That is the one you set through the View.Cursor field the way you already are, and keeping it the real cursor matters because it drives blink and IME/composition positioning. Every other caret, the remote collaborators in your Loro case or extra carets in single-user multi-cursor, is not a cursor at all; it is a styled cell you draw into the View() string.

The detail that bit me: style the cell by display column, not byte offset. For each non-primary caret at (x, y), reverse-video or background-color the single grapheme already sitting at that column so the character still shows through the block. If you splice the ANSI in at a byte index, any wide rune or tab to the left shoves the block off by a column and the whole tail of the line drifts right. So lay the line out into display cells first, then recolor cell x. For a selection, the anchor-to-head range is a separate background span you paint before the caret cell, one color per peer.

On the Kitty multiple-cursors protocol you linked: it standardizes cursor shape per terminal, not N independently addressable blinking cursors for app logic, and Bubble Tea has no portable abstraction over it, so "one real cursor plus N drawn cells" is the answer that works across terminals today. Happy to share the width-aware render helper from nook if it would help.