History recall and location behavior like cmd.exe has

[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.

[UberKluger]

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]

@UberKlug

Thanks very much for your detailed reply

It's been so long since I originally posted that without any replies I figured I was the only one that cared about the issue.

Thanks for letting me know about AcceptAndGetNext, I will check it out.

I'd really like to see the default behavior work like cmd.exe worked because that seems much more natural and expected than the current behavior.