ListView does not render the first selection after reuse in Vi insert mode
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 65/100
Research direction
Reproduce with pwsh -noprofile, Vi edit mode, and ListView prediction settings, then compare the first DownArrow after reopening ListView with the initial use. Trace the ListView navigation path and Vi insert-mode handling. Done means the first press visibly highlights the internally selected item on every reuse, with Enter and subsequent navigation remaining consistent.
Written by the indexing model from the issue text.
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
Long-time Vi mode user. For a couple of years, I've been dealing w/ an obscure behavior and finally taking time to report it.
Issue: In Vi insert mode with PredictionViewStyle set to ListView, the first DownArrow press after reusing the list selects a history item internally but fails to render its highlight until another navigation key is pressed.
More Detail:
When using these PSReadLine options:
Set-PSReadLineOption -PredictionViewStyle ListView
Set-PSReadLineOption -EditMode Vi
the first DownArrow press in the prediction selects a history entry internally without visually rendering the selection highlight.
Pressing Enter at that point executes/accepts the first history item, which indicates that the item was selected despite no visible highlight. Pressing DownArrow a second time causes the selection highlight to appear. After that, UpArrow and DownArrow behave and render normally.
Note: The issue does not occur the first time ListView is used in a new PowerShell session; it only begins after ListView has already been used once.
Entering Vi normal mode and then returning to insert mode resets the behavior, e.g. Esc + i. After that, the first DownArrow press renders correctly again, until the issue recurs.
Environment data
PS Version: 7.6.3
PS HostName: ConsoleHost
PSReadLine Version: 2.4.5
PSReadLine EditMode: Vi
OS: 10.0.26100.1 (WinBuild.160101.0800)
BufferWidth: 180
BufferHeight: 50
Steps to reproduce
- Run
pwsh -noprofile - Run
Set-PSReadLineOption -EditMode Vi - Run
Set-PSReadlineOption -PredictionViewStyle ListView - In Vi insert mode, type text that produces history predictions
- Use the ListView and navigate it with DownArrow (on the first use in a new session, the highlight appears as expected)
- Complete or dismiss the ListView (e.g. ESC to dismiss and
ccto clear the line/command) - Trigger ListView again and press DownArrow once
On the second and later uses of ListView:
- The first DownArrow press appears to do nothing visually.
- No entry is highlighted.
- Pressing Enter accepts or runs the first list item, indicating that the selection changed internally.
- Pressing DownArrow a second time causes the visual highlight to appear.
- Subsequent UpArrow and DownArrow presses render correctly.
Expected behavior
- Each
DownArrowpress in ListView should visibly move the selection to the next prediction. - On the first press, the first matching history entry should be highlighted immediately.
- The visible highlight and the internally selected item should always remain in sync.
- This should behave consistently every time ListView is opened while in Vi insert mode.
Actual behavior
- After ListView has been used once, reopening it in Vi insert mode produces no visible highlight on the first
DownArrowpress. - The first item appears unselected, but it is selected internally.
- Pressing
Enteraccepts/runs that first item despite the missing highlight. - A second
DownArrowpress makes the highlight appear, after which navigation renders normally. - Pressing
Escand thenitemporarily resets the behavior.
- Dominant language
- C#
- Stars
- 4.4k
- Forks
- 341
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from PowerShell/PSReadLine
-
Needs-Triage :mag:
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
PowerShell/PSReadLine#5205 ·
-
Needs-Triage :mag:
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
PowerShell/PSReadLine#5195 ·
-
Needs-Triage :mag:
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
PowerShell/PSReadLine#5121 ·
-
Needs-Triage :mag:
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
PowerShell/PSReadLine#5045 ·
-
Area-CommandHelp Issue-Enhancement
Difficulty 1/5 Under an hour Newbie friendliness 68/100
PowerShell/PSReadLine#3470 · 3 reactions ·
All issues in PowerShell/PSReadLine
Similar issues
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 75/100
sillsdev/languageforge-lexbox#2665 ·
-
bug documentation frontend
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
azurenoops/spin_agent#975 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
:watch: Not Triaged 11.0 fundamentals/subsvc
Difficulty 2/5 1-3 hours Newbie friendliness 92/100
dotnet/AspNetCore.Docs#37699 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
SubtitleEdit/subtitleedit#15108 · 1 comment ·