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?

[zadjii-msft]

from @LucasDondo in #15854

The problem is that sometimes a command takes too long to execute (and in the meantime, we want to start writing the one that follows). For example, we run something like python -m pip install --upgrade pip. But during the installation, we remember we must also install Django. So, instead of waiting for the previous execution to end and just then being able to write python -m pip install django, this feature would let users start writing the following command even before the previous one has finished. This way, while pip gets updated, we can start writing python -m install django. If I press enter, that command should be run right after the previous finishes. If not, then at least we already have it written for the very moment the first command finishes.

P.D.: While testing, I saw that this is a thing already. What is missing is what I describe in the next paragraph: somehow show what is being written.

I_can_write_but_I_cannot_see_what_I_write.MP4

What I want to happen is that instead of the keyboard cursor being positioned at the very end of the terminal and that whatever I write in it get overlaped with the text generated by the previous command, it was positioned also at the bottom of the terminal but in a different "section", after the command's output. Whatever you write there is persistent and once the command execution comes to an end, whatever you wrote gets in the "traditional input of commands" (what appears in the video after the tree command finished).