Show and allow editing of typeahead

[MikeHillberg]

Description of the new feature/enhancement

While a command is running today, you can be typing the next command(s), but you can't see what you're typing.
It would be wonderful if for example a horizontal splitter showed up at the bottom of the screen,
above which would be the console output of the currently running command,
and below which would be a standard editing line.
Type more than one command, and the splitter moves up to make room.

[KalleOlaviNiemitalo]

This might be covered by #8178.

[zadjii-msft]

Okay, so I really like the idea, but I'm having a hard time finding a way that would be possible to implement. The Terminal doesn't really have any idea of when text is being buffered as input. I suppose maybe the console does. Though, that's more just there's a set of input in the input buffer that the client hasn't read yet.

I'm not sure there's a good generic way to implement this in a cross-platform like manner. Like, maybe we could come up with a way of saying "my input buffer contains asdf", and allow the Terminal to tell the console "no, now your buffer contains asdf\nqwerty". However, I'm pretty confident that the pty/tty on *nix would never do a similar thing. On those platforms, the input buffer is just a dumb pipe, so there's no way for the terminal to inspect if there's anything that's still in that buffer. I'd rather keep the Terminal as similar to a *nix-like terminal as possible, and not further fragment the space.

Even on Windows, I don't think this would work totally right. I'm pretty sure that WSL, for example, will eagerly drain the input buffer from the console, and just yeet it into the tty inside of WSL. At this point, the console doesn't even think there's any input to buffer (even if there is within WSL).

Now, we could do something totally else. I don't think it would be as seamless as "start typing while a command is running and we'll automatically open a TextBox to edit the input", but it could achieve something similar. I'm thinking we instead have some action for "Open input buffer overlay". This would manually open the editor on top of the terminal control, where you could now edit the input. We could support multiple lines of input, maybe even multiple cursors in there. We could have it submit on enter, or on ctrl+enter, or whatever the user wants to configure, and then we'll just send everything in that box straight to the connection on the other side.

[MikeHillberg]

Yeah, I don't understand the division between Terminal and console so wasn't sure how feasible it would be. I type ahead a lot, and I should trust my fingers, but it would be nice to see what I'm typing, and sometimes I know I need to make an edit :)

[zadjii-msft]

gods now I'm terribly aware of every single time I'm doing this

<crazy idea time>

Okay, so we need a way for the shell to say "I'm going to start a command now", and a way to say "I'm ready for input again". If you start typing between those two, we'll stick them in the buffer, instead of sending them to the terminal. If you do nothing between those two, then whatever, nothing happens.

Open questions

• how does something like vim play with this? tmux?
  • vim would want to emit the "I'm ready for input", probably immediately, right? They'd need to explicitly add code to enable this, that's probably not a good solution. Entering the alt buffer might be a good solution, but then there's tmux
  • tmux runs in the alt buffer. Shells within it will want to enter & exit. Presumably, if you're using this feature, then you're not switching tmux panes during this buffering. You'd be in the context of a single pane, buffer some commands, submit them, then switch to other panes?
  • That raises the question of things like arrow key input - that we probably ignore, right? This is a command buffer, not a generic input buffer
  • what about mouse input? If you click in the terminal such that it would send mouse input, do we
    • send the buffered text, then the mouse event?
    • dismiss the buffer UI, then send the mouse event?
    • dismiss the buffer UI(but keep the text in it), then send the mouse event?
    • ignore the mouse event entirely?
• Does this work for something like ssh?

How do we implement this for various shells?

• bash: Link to SuperUser post describing how a user could use that
• powershell: ? this has got to exist....
• zsh: Implied by the bash post that precmd and preexec are what we want
• cmd: Impossible, unless we shipped a new version of cmd. Various alternatives to cmd that have been thrown around in the past:
  • yori?
  • clink?