Activity

1. MikeHillberg

   added

   Issue-FeatureComplex enough to require an in depth planning process and actual budgeted, scheduled work.Complex enough to require an in depth planning process and actual budgeted, scheduled work.

   on Jul 17, 2021
2. ghost added

   Needs-TriageIt's a new issue that the core contributor team needs to triage at the next triage meetingIt's a new issue that the core contributor team needs to triage at the next triage meeting

   on Jul 17, 2021
3. ghost added

   Needs-Tag-FixDoesn't match tag requirementsDoesn't match tag requirements

   on Jul 17, 2021
4. KalleOlaviNiemitalo commented on Jul 17, 2021

   

   Kalle Olavi Niemitalo (KalleOlaviNiemitalo)

   on Jul 17, 2021

   More actions

   This might be covered by #8178.
5. Mike Griese (zadjii-msft)

   added

   Product-TerminalThe new Windows Terminal.The new Windows Terminal.

   on Jul 20, 2021
6. zadjii-msft commented on Jul 21, 2021

   

   Mike Griese (zadjii-msft)

   on Jul 21, 2021

   Member

   More actions

   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.
7. Mike Griese (zadjii-msft)

   added

   Area-ExtensibilityA feature that would ideally be fulfilled by us having an extension model.A feature that would ideally be fulfilled by us having an extension model.

   on Jul 21, 2021
8. ghost removed

   Needs-Tag-FixDoesn't match tag requirementsDoesn't match tag requirements

   on Jul 21, 2021
9. Mike Griese (zadjii-msft)

   added this to the Icebox ❄ milestone on Jul 21, 2021
10. MikeHillberg commented on Jul 21, 2021

    

    MikeHillberg

    on Jul 21, 2021

    Author

    More actions

    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 :)
11. zadjii-msft commented on Jul 22, 2021

    

    Mike Griese (zadjii-msft)

    on Jul 22, 2021

    Last edited by zadjii-msft

    Member

    More actions

    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?
12. Dustin L. Howett (DHowett)

    modified the milestones: Icebox ❄, Terminal Backlog on Jul 22, 2021
13. Dustin L. Howett (DHowett)

    removed

    Needs-TriageIt's a new issue that the core contributor team needs to triage at the next triage meetingIt's a new issue that the core contributor team needs to triage at the next triage meeting

    on Jul 22, 2021
14. Dustin L. Howett (DHowett)

    modified the milestones: Terminal Backlog, Icebox ❄ on Jul 22, 2021
15. zadjii-msft commented on Aug 21, 2023

    

    Mike Griese (zadjii-msft)

    on Aug 21, 2023

    Member

    More actions

    from Lucas Dondo (@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).
16. sachinjoseph commented on Jul 26, 2025

    

    Sachin Joseph (sachinjoseph)

    on Jul 26, 2025

    More actions

    I opened #4386 in Jan 2020 but Dustin L. Howett (@DHowett) closed it almost immediately with the tag Resolution-External 🤷‍♂️
17. microsoft

    locked and limited conversation to collaborators on Jul 26, 2025