Repository navigation
While using History search, hitting escape to clear the line causes the line input to get stuck #97
Description
Activity
It sounds like there was an exception in PSReadline. If you still have the session open, can you take a look in $error - if any of the errors come from PSReadline, can you paste the call stack from the exception?
Here is what I pulled from the $error after recreating it:
Exception calling "ReadLine" with "0" argument(s): "Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index"
At F:\Dropbox\Jon\Coding\PSModules\PSReadLine\PSReadLine.psm1:9 char:5-
[PSConsoleUtilities.PSConsoleReadLine]::ReadLine() -
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~- CategoryInfo : NotSpecified: (:) [], MethodInvocationException
- FullyQualifiedErrorId : ArgumentOutOfRangeException
Exception calling "ReadLine" with "0" argument(s): "Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index"
At F:\Dropbox\Jon\Coding\PSModules\PSReadLine\PSReadLine.psm1:9 char:5-
[PSConsoleUtilities.PSConsoleReadLine]::ReadLine() -
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~- CategoryInfo : NotSpecified: (:) [], MethodInvocationException
- FullyQualifiedErrorId : ArgumentOutOfRangeException
Get-Variable : Cannot find a variable with the name 'PsGetDirectoryUrl'.
At F:\Dropbox\Jon\Coding\PSModules\PsGet\PsGet.psm1:1302 char:11- if (-not (Get-Variable -Name PsGetDirectoryUrl -Scope Global -ErrorAction Silent ...
-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~- CategoryInfo : ObjectNotFound: (PsGetDirectoryUrl:String) [Get-Variable], ItemNotFoundException
- FullyQualifiedErrorId : VariableNotFound,Microsoft.PowerShell.Commands.GetVariableCommand
After I pulle dthese I ran it one more time in a new session: after it started again my cmd line looked like:
Coding:\repos\SW-Configs [master]> git status$errorBut when I hit enter, it ran only the $Error portion, it is like the git status was clear, just not off the screen. weird.
The only difference in my setup is I installed my modules (using psget -destination) in a custom directory, but before I did that, it did the same thing when installed in the default $profile\modules.
-
I've also hit this. My exception looks very similar, except I can't reproduce it right now to get exact text - I'll post more info when it happens to me next. Deuce199 - you can hit Ctrl-C to abort the command rather than hitting enter.
Thanks, I saw the same issue yesterday, and it looks related to another issue that I am aware of but haven't addressed yet related to undo/redo.
I have a repro, so I don't think I need any more details for now.
Is Esc (RevertLine) not supposed to clear the line when you have navigated back in the history? Is it possible to make hitting Esc twice clear the line even when you are in the history?
Esc is literally repeating undo until you've undone the whole line.
The bug is a combination of how undo and history work together.
History items retain their undo histories. For example, you can recall an item from history (doesn't matter how you do this, search or not search) and then use undo/redo like it was the current line.
I'm not sure how often this is useful, but GNU readline does it, so that's what I implemented.
Note that undo/redo won't work for items loaded from PowerShell history (before PSReadline is loaded), it only works for commands entered in the current session. And now that I point this out, you may notice Esc won't revert lines that were loaded from history. I think bash works the same way but I forget.
I haven't thoroughly tested undo yet or I would have noticed this bug before.
This bug happens because history search finds the original line entered into history, but undo has actually modified the line. They are out of sync causing an exception. Any exception in PSReadline ends up cause odd behavior, e.g. looking like you have a partially entered line, but you can't edit that part of the line and no more syntax coloring.
One possible fix is to only support undo on the current line (and not emulate GNU readline). Esc could use undo if it's on the current line (so you can redo if it was accidental) but otherwise clear the line. This is probably a simple fix, but possibly a confusing experience at times.
I'll probably find a fix that keeps undo on all history items, but I haven't had the time to find the best fix yet.
How about this: For history entries that do not have undo data, add a dummy undo history item that inserts the whole line. Then undoing it will just clear the line as expected, and redo will restore it.
Yeah, I'll probably do that. It doesn't fix the issue initially reported, but it's a good idea nonetheless.
If you are using the up and down arrow keys to go through history commands, this can be a few commands or alot, and then hit the "esc" key to clear the line for new input, about half the time the input line entry gets stuck, and nothing clears it. you have to hit enter, to clear the line, errors of not. It will also then run whatever is on the line even though you cannot clear it.
I have reproduced this, but heading to a git repo or another folder (I used my git repo folder), using a few git commands, and then arrowing through the history list, and occasionally hitting escape to clear the line. It will get stuck after a few times.