Repository navigation
Space key has no visible effect until another character is typed in terminal mode #3268
Description
What happened
In Ovis 0.5.0, pressing Space while typing in terminal mode has no immediate visible effect. The space only becomes visible after I type another character.
Steps to reproduce:
- Open a terminal pane in Ovis and switch to terminal mode.
- Type some text.
- Press Space.
- Observe that the input does not visibly update.
- Type another character—the space then becomes visible.
Expected behavior:
Pressing Space should immediately update the input and advance the cursor.
Actual behavior:
The visible update is delayed until the next character is typed.
Environment:
- Ovis: 0.5.0 (commit 347a989)
- herdr: 0.9.5
- Server and client OS: macOS 27.3 (build 26C5035r)
- Hardware: Apple M4 Pro, arm64
- Browser: Safari 27.3 (22626.1.12.11.4)
- Installation: herdr plugin
- Connection: same Mac, localhost port 7317
- Authentication: local access, no sign-in required
- Bun: 1.4.3
How often
Every time
Ovis version
0.5.0 (in previous it worked)
How it runs
herdr plugin
Server PC
MacOs 27.3, herder 0.9.5
Device and browser
MacOs 27.3, Safari 27.3
How the device reaches the server
This PC (localhost)
How it signs in
None
Agent and PC
No response
Screenshots or logs
No response
Activity
matiemer commentedon Nov 7, 2026
Independent reproduction on Linux Mint 22.3 x86-64, Chrome 157, Ovis 0.5.0 (
347a989d1c2c71ab273c1a6d9c900054568f97b8), herdr 0.9.5, local herdr plugin installation.I tested an isolated Ovis terminal using Chrome DevTools key events, with ~600 ms between keys, in Claude Code 2.1.319 and Codex CLI 0.167.0. Shell and Python
input()also reproduced it. No agent prompt was submitted.Observation: after typing
a, Space,b, Space, Space,c, the visible.ghostty-cursorstayed at the previous column after each space. The underlying xterm helper textarea's position advanced by one cell per space. The next letter made the visible cursor catch up, including both spaces. In a separate Python test,print(repr(input()))returned'x y', confirming that the space reached the program. After waiting over 600 ms following a space, the mismatch remained.A faster sequence (~25 ms per key) delivered the trailing space and the cursors had caught up when inspected after the sequence, so this does not happen visibly on every fast run.
This appears related to the cursor-only movement in #3266. A direct Ghostty component test found that cursor-only escape sequences can move the cursor while
GhosttyVt.frame()returnsfalse; the overlay updates its visible cursor only when that return value is true (frame, overlay). This is a concrete cursor-only rendering defect, but I did not capture the actual terminal bytes for a live space press, so I cannot establish that every space follows this exact path. In the component test, writing a literal space directly did mark the frame changed.fix(terminal): move the drawn cursor on arrow keys and a typed space (d…