v2: textinput Cursor() X ignores scroll offset when input overflows width

[thomas-mangin]

Description

textinput.Model.Cursor() returns an X coordinate based on m.Position() (the absolute cursor position in the full value), but when the input text is wider than the configured width, the textinput scrolls horizontally. View() correctly uses m.pos - m.offset for the visible cursor column, but Cursor() does not account for the scroll offset.

This means the hardware cursor (used when SetVirtualCursor(false)) is placed at the wrong column when the input is scrolled.

Version

charm.land/bubbles/v2 v2.1.0

Affected code

In textinput.go, the Cursor() method:

func (m Model) Cursor() *tea.Cursor {
    if m.useVirtualCursor || !m.Focused() {
        return nil
    }

    w := lipgloss.Width
    promptWidth := w(m.promptView())
    xOffset := m.Position() + promptWidth   // <-- uses absolute position
    if m.width > 0 {
        xOffset = min(xOffset, m.width+promptWidth)
    }
    // ...
}

Compare with View() which correctly adjusts for scroll:

value := m.value[m.offset:m.offsetRight]
pos := max(0, m.pos-m.offset)              // <-- uses scroll-adjusted position

Reproduction test

package textinput_test

import (
	"strings"
	"testing"

	"charm.land/bubbles/v2/textinput"
)

func TestCursorXAccountsForScrollOffset(t *testing.T) {
	m := textinput.New()
	m.Focus()
	m.SetVirtualCursor(false)
	m.CharLimit = 200
	m.SetWidth(20)

	text := strings.Repeat("a", 30)
	m.SetValue(text)
	m.CursorEnd()

	m, _ = m.Update(nil)

	cur := m.Cursor()
	if cur == nil {
		t.Fatal("Cursor() returned nil")
	}

	width := m.Width()
	t.Logf("width=%d  pos=%d  cursor.X=%d", width, m.Position(), cur.X)

	if cur.X > width {
		t.Errorf("Cursor().X = %d, exceeds viewport width %d; "+
			"Cursor() uses Position() (absolute) instead of the "+
			"scroll-adjusted visible column", cur.X, width)
	}
}

Output:

width=20  pos=30  cursor.X=22
Cursor().X = 22, exceeds viewport width 20

Expected behavior

Cursor().X should reflect the visible cursor column within the viewport (i.e., m.pos - m.offset + promptWidth), consistent with how View() renders the cursor.

Impact

Any consumer using the hardware cursor (SetVirtualCursor(false)) with text longer than the input width will see the terminal cursor placed at the wrong column. We hit this building an SSH-accessible CLI where the hardware cursor is needed to avoid re-render-induced text selection breakage.

Suggested fix

Replace m.Position() with m.Position() - m.offset in Cursor() (the offset field is unexported, so this must be fixed in the package):

xOffset := (m.pos - m.offset) + promptWidth

[hiSandog]

Using m.pos - m.offset aligns the hardware cursor with View(), but the regression should assert display-cell width rather than rune count. Wide CJK characters, combining marks, a styled/wide prompt, cursor-at-start after scrolling, and selection edits can all change the visible column. A table test comparing Cursor().X with the rendered cursor position across those cases would prevent fixing the ASCII overflow example only.

[sifhg]

I just came across this issue too and it's making it difficult working with the cursor when using textinput, so I'm glad to see it's already reported.

Instead of changing the behaviour of m.Position() as this might break other projects that depend on bubbles, I'd suggest either defining a method that returns the relative position (maybe m.RelativePosition()) or one that returns the offset so we can easily compute the cursor position (m.Offset).

[mastersingh24]

Still present in v2.1.1 — textinput/textinput.go is byte-identical to v2.1.0, so the version field above can be read as "v2.1.0 and v2.1.1".

Worth linking: #906 reports a second defect in the same expression — m.Position() is a rune index while promptWidth is a display width, so wide runes misplace the caret independently of any scrolling. Neither issue references the other, but they are the same two terms:

xOffset := m.Position() + promptWidth
//         ^^^^^^^^^^^^   rune index, and ignores m.offset
//                        ^^^^^^^^^^^ display width

A single expression fixes both, and mirrors what View() already does twenty lines earlier:

xOffset := promptWidth + ansi.StringWidth(string(m.value[m.offset:m.pos]))

ansi.StringWidth resolves #906 (width, not rune count); slicing from m.offset resolves this issue. The existing min(xOffset, m.width+promptWidth) clamp then becomes redundant rather than load-bearing — right now it is what pins the caret to the right edge once the value scrolls.

On @sifhg's point about not changing Position(): agreed, and worth separating the two cases, because they are not equally workaroundable downstream.

• textinput: Cursor() returns incorrect X position for wide (CJK) characters #906 is partially fixable from outside. When ansi.StringWidth(m.Value()) <= width the value cannot have scrolled, so m.offset is provably 0 and a caller can compute the correct X from the exported Value() and Position() alone.
• This issue is not fixable from outside at all. m.offset has no exported accessor — I checked the full exported method set — and reproducing it downstream would mean reimplementing handleOverflow's scroll arithmetic against state that is only observable indirectly.

So even if the fix inside Cursor() is deferred, exporting an Offset() int (or a RelativePosition() int returning m.pos - m.offset) would unblock callers, which the current API cannot.

[thomas-mangin]

As #1005 highlighted, it is important to count cells and not runes.