UberKluger
commented
4 years ago This behaviour is particularly annoying when the sequence of commands is a long way back in the history. You can set a key handler to invoke AcceptAndGetNext. Emacs mode already has ctrl-o, I used Ctrl+Alt+Enter (because both Alt+Enter and Shift+Alt+Enter are grabbed by Windows to toggle full screen) but you could use plain Enter provided you didn't mind PSReadLine going Ding if there is no next command, e.g. you entered a new command so it goes at the end of history.
However, even though this workaround provides the basic functionality described above, it then leads to other issues (some have been mentioned elsewhere #514). New commands from concurrent sessions (i.e. entered after the current session started) are skipped when traversing history using up and down arrow (deliberate behaviour) but can be retrieved using search functions (F8, ctrl+r/s). Unfortunately, AcceptAndGetNext behaves like up/down and ignores the "next" command (from the other session), returning to the end of history.
Probably needs a navigation state flag. If you have only used arrow keys then only retrieve current and previous sessions. Once you include concurrent sessions by using history search functions, all history is available (even to arrows) until the command is accepted or cancelled. Further, the navigation state is maintained if using AcceptAndGetNext.
JoeSalmeri
Environment data
Name Value
PSVersion 6.1.0 PSEdition Core GitCommitId 6.1.0 OS Microsoft Windows 10.0.17763 Platform Win32NT PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...} PSRemotingProtocolVersion 2.3 SerializationVersion 1.1.0.1 WSManStackVersion 3.0 ` -->
Steps to reproduce or exception report
NOTE: that the actually commands entered do NOT matter I provide this so that we have some history to use for the explanation:
Type "dir 1.txt" and press enter Type "dir 2.txt" and press enter Type "dir 3.txt" and press enter Press UpArrow until you get to dir 1.txt Press Enter Press DownArrow
When you press DownArrow nothing happens because you are at the end of the history.
If you repeat that using cmd.exe then after you pressed UpArrow to reach dir 1.txt and then hit enter, then the DownArrow would have brought up dir 2.txt since it was the next item in the history. cmd.exe seemed to track set your position in the history after you used it to execute a previous history item.
This was extremely convenient when you wanted to recall and repeat a sequence of commands because after the first recall you pressed DownArrow which put you on the next command and subsequent DownArrows would let you re-execute the sequence one a time.