-
Notifications
You must be signed in to change notification settings - Fork 316
Description
Prerequisites
- Write a descriptive title.
- Make sure you are able to repro it on the latest released version
- Search the existing issues, especially the pinned issues.
Exception report
N/A
Screenshot
N/A
Environment data
PS Version: 7.5.2
PS HostName: ConsoleHost (Windows Terminal)
PSReadLine Version: 2.4.3-beta3
PSReadLine EditMode: Windows
OS: 10.0.26100.1 (WinBuild.160101.0800)
BufferWidth: 150
BufferHeight: 40
Steps to reproduce
In Screen Reader mode, the way rendering works is to first calculate the common prefix between the last rendered string and the current string, and then move cursor (as needed) to the position of commonPrefixLength
to erase the rest of the previous rendering and write the diff part from the current string.
There could be a problem when user moves the cursor and then inserts (or select-then-delete) a sequence of characters.
One example:
- Previous line is
abcdef
, cursor is at the letterd
- Press
ctrl+v
to pastedefghi
In this case, the new buffer is abcdefghidef
, and commonPrefixLength == previousBuffer.Length
, but the cursor is still at the first letter d
when code flow reaches here. Then writting out the new diff ghidef
will result in abcghidef
displayed in terminal.
When execution reaches the screen reader rendering, _current
is already changed -- it no longer reflects where the cursor is at. This uncommon scenario is tricky, and it potentially could affect the commonPrefixLength != previousBuffer.Length
case.
The original discussion is at #4854 (comment)
Expected behavior
Cursor position needs to be adjusted in those cases. For the specific example described above, the result text on terminal should be abcdefghidef
.
Actual behavior
For the example described above, the result text on terminal should be abcghidef
.