terminal/.github
Mike Griese 03ebe514e9
Add support for running a commandline in another WT window (#8898)
## Summary of the Pull Request

**If you're reading this PR and haven't signed off on #8135, go there first.**

![window-management-000](https://user-images.githubusercontent.com/18356694/103932910-25199380-50e8-11eb-97e3-594a31da62d2.gif)

This provides the basic parts of the implementation of #4472. Namely:
* We add support for the `--window,-w <window-id>` argument to `wt.exe`, to allow a commandline to be given to another window.
    * If `window-id` is `0`, run the given commands in _the current window_.
    * If `window-id` is a negative number, run the commands in a _new_ Terminal window.
    * If `window-id` is the ID of an existing window, then run the commandline in that window.
    * If `window-id` is _not_ the ID of an existing window, create a new window. That window will be assigned the ID provided in the commandline. The provided subcommands will be run in that new window.
    * If `window-id` is omitted, then create a new window.


## References
* Spec: #8135
* Megathread: #5000
* Project: projects/5

## PR Checklist
* [x] Closes #4472
* [x] I work here
* [x] Tests added/passed
* [ ] Requires documentation to be updated - **sure does**

## Detailed Description of the Pull Request / Additional comments

Note that `wt -w 1 -d c:\foo cmd.exe` does work, by causing window 1 to change 

There are limitations, and there are plenty of things to work on in the future:
* [ ] We don't support names for windows yet
* [ ] We don't support window glomming by default, or a setting to configure what happens when `-w` is omitted. I thought it best to lay the groundwork first, then come back to that.
* [ ] `-w 0` currently just uses the "last activated" window, not "the current". There's more follow-up work to try and smartly find the actual window we're being called from.
* [ ] Basically anything else that's listed in projects/5.

I'm cutting this PR where it currently is, because this is already a huge PR. I believe the remaining tasks will all be easier to land, once this is in. 

## Validation Steps Performed

I've been creating windows, and closing them, and running cmdlines for a while now. I'm gonna keep doing that while the PR is open, till no bugs remain.

# TODOs
* [x] There are a bunch of `GetID`, `GetPID` calls that aren't try/caught 😬 
  -  [x] `Monarch.cpp`
  -  [x] `Peasant.cpp`
  -  [x] `WindowManager.cpp`
  -  [x] `AppHost.cpp`
* [x] If the monarch gets hung, then _you can't launch any Terminals_ 😨 We should handle this gracefully.
  - Proposed idea: give the Monarch some time to respond to a proposal for a commandline. If there's no response in that timeframe, this window is now a _hermit_, outside of society entirely. It can't be elected Monarch. It can't receive command lines. It has no ID.  
  	- Could we gracefully recover from such a state? maybe, probably not though.
    -  Same deal if a peasant hangs, it could end up hanging the monarch, right? Like if you do `wt -w 2`, and `2` is hung, then does the monarch get hung waiting on the hung peasant?
  - After talking with @miniksa, **we're gonna punt this from the initial implementation**. If people legit hit this in the wild, we'll fix it then.
2021-02-10 11:28:09 +00:00
..
actions/spelling Add support for running a commandline in another WT window (#8898) 2021-02-10 11:28:09 +00:00
ISSUE_TEMPLATE Configure the options available in the issue list (#8114) 2020-11-04 17:18:24 -08:00
linters Add support for autodetecting URLs and making hyperlinks (#7691) 2020-10-28 20:24:43 +00:00
workflows ci: update to Spell check to 0.0.17a (#9014) 2021-02-03 11:17:38 -08:00
PULL_REQUEST_TEMPLATE.md Add schema check to PR template (#6599) 2020-06-19 12:06:23 -07:00