Skip to content

Fix cursor drift when a wrapped line starts on an exact wrap boundary - #2084

Open
gyanu2507 wants to merge 1 commit into
prompt-toolkit:mainfrom
gyanu2507:fix/cursor-wrap-boundary
Open

Fix cursor drift when a wrapped line starts on an exact wrap boundary#2084
gyanu2507 wants to merge 1 commit into
prompt-toolkit:mainfrom
gyanu2507:fix/cursor-wrap-boundary

Conversation

@gyanu2507

Copy link
Copy Markdown

With wrap_lines=True, get_height_for_line treated text that fills the window width exactly as still sitting on the current row. _scroll_when_linewrapping measures the text before the cursor, so an exact fill means the cursor is already on the next visual row. The window then under-scrolls, the wrapped cursor cell is never painted, and it looks like the cursor drifted — usually when a space becomes the first character of a wrapped line. Arrow keys recalculate the position and snap it back.

This counts that extra row when measuring up to the cursor (both the fast path and the get_line_prefix path).

Fixes #2071

…dary.

get_height_for_line treated text that fills the width exactly as still on the current row. The cursor is already on the next visual line in that case, which is how a leading wrapped space made it look like it had drifted.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Cursor drift after auto-wrap when first char of wrapped line is a space

1 participant