<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Proto-extensions spec
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Is documentation
* [x] I work here
* [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
This introduces an addendum to the Terminal Settings Model spec that
covers inheritance and fallback. Basically, settings objects will now
have a reference to a parent object. If the settings object does not
have a setting defined, it will ask its parent to resolve the value. A
parent is set using the `Clone()` function. `Copy()` is used to copy the
value and structure of the settings model, whereas `Clone()` is used to
copy a reference to the settings model and build an inheritance tree.
## References
#6904 - Terminal Settings Model Spec
#1564 - Settings UI
## Summary of the Pull Request
This introduces a spec for (what I like to call) winrt TerminalSettings. Basically, we need to move over some of the code that resides in TerminalApp that relates to the settings model, then expose some of the settings objects as winrt objects. Doing so will allow us to access/modify settings across different project layers (a must-have for the Settings UI).
## References
#885 - winrt Terminal Settings issue
#1564 - spec for most of the backend work for Settings UI
* This is a mini-spec for how I see this working
* good bot
* These were some typos
* Addd a future consideration about the command palette and commands
* Update spec to reflect discussion with Carlos
* update spec to reflect investigations in Command Palette Addenda 1
* add references to #6899, and minor bits of review feedback
* add `remainingProfiles` as a way of adding all the user's other profiles quickly to the menu as well
* clarify why we're not doing it in the profiles list
* no two commits do not contain a misspelling of separate
## Summary of the Pull Request
⚠️ This spec has been moved from #6902. That version was branched off the new tab menu customization, and had a terribly convoluted git history. After discussion with the team, we've decided that it's best that this spec is merged atomically _first_, and used as the basis for #5888, as opposed to the other way around.
> This document is intended to serve as an addition to the [Command Palette Spec],
> as well as the [New Tab Menu Customization Spec].
>
> As we come to rely more on actions being a mechanism by which the user defines
> "do something in the Terminal", we'll want to make it even easier for users to
> re-use the actions that they've already defined, as to reduce duplicated json as
> much as possible. This spec proposes a mechanism by which actions could be
> uniquely identifiable, so that the user could refer to bindings in other
> contexts without needing to replicate an entire json blob.
>
## PR Checklist
* [x] Specs: #6899
* [x] References: #1571, #1912, #3337, #5025, #5524, #5633
* [x] I work here
## Detailed Description of the Pull Request / Additional comments
_\*<sup>\*</sup><sub>\*</sub> read the spec <sub>\*</sub><sup>\*</sup>\*_
[Command Palette Spec]: https://github.com/microsoft/terminal/blob/master/doc/specs/%232046%20-%20Command%20Palette.md
[New Tab Menu Customization Spec]: https://github.com/microsoft/terminal/blob/master/doc/specs/%231571%20-%20New%20Tab%20Menu%20Customization.md
Co-authored-by: Mike Griese <zadjii@gmail.com>
## Summary of the Pull Request
This spec is a subset of #5772, but specific to per-profile tab colors. We've had enough requests for that in the last few days that I want to pull that feature out into it's own spec, so we can get that approved and implemented in a future-proof way.
> This spec describes a way to specify tab colors in a profile in a way that will
> be forward compatible with theming the Terminal. This spec will be largely
> dedicated to the design of a single setting, but within the context of theming.
>
## PR Checklist
* [x] Specs: #1337
* [x] References: #5772
* [x] I work here
## Detailed Description of the Pull Request / Additional comments
_\*<sup>\*</sup><sub>\*</sub> read the spec <sub>\*</sub><sup>\*</sup>\*_
## Summary of the Pull Request
This proposes a change to how Terminal will scroll in response to newly
generated output. The Terminal will scroll upon receiving new output if
the viewport is at the bottom of the scroll history and no selection is
active.
This spec also explores the possibility of making this response
configurable with a `snapOnOutput` profile setting. It also discusses
the possibility of adding a scroll lock keybinding action.
## PR Checklist
* [X] Spec for #980
## Summary of the Pull Request
This is another iteration on the Command Palette spec, from #5674. These were some ideas that were tossed around by @DHowett, @cinnamon-msft and myself, formalized here. I proposed this as an addendum to the original spec, since I think the first made sense atomically, and this only makes sense as a set of changes to the original. I didn't want to go hacking up the original doc to add this set of changes.
**There are two proposals in this spec - they should be viewed as two atomic units. They can be accepted or rejected independently. I'm suggesting we approve both. They work _together_. I'm realizing now that this is worded confusingly, and it's on me to fix that.**
## PR Checklist
* [x] Another spec in the #2046 / #5400 saga
* [x] I work here
* [x] _is a doc_
> ## Abstract
>
> This document is intended to serve as an addition to the [Command Palette Spec].
> While that spec is complete in it's own right, subsequent discussion revealed
> additional ways to improve the functionality and usability of the command
> palette. This document builds largely on the topics already introduced in the
> original spec, so readers should first familiarize themselves with that
> document.
>
> One point of note from the original document was that the original specification
> was entirely too verbose when defining both keybindings and commands for
> actions. Consider, for instance, a user that wants to bind the action "duplicate
> the current pane". In that spec, they need to add both a keybinding and a
> command:
>
> ```json
> {
> "keybindings": [
> { "keys": [ "ctrl+alt+t" ], "command": { "action": "splitPane", "split":"auto", "splitMode": "duplicate" } },
> ],
> "commands": [
> { "name": "Duplicate Pane", "action": { "action": "splitPane", "split":"auto", "splitMode": "duplicate" }, "icon": null },
> ]
> }
> ```
>
> These two entries are practically the same, except for two key differentiators:
> * the keybinding has a `keys` property, indicating which key chord activates the
> action.
> * The command has a `name` property, indicating what name to display for the
> command in the Command Palette.
>
> What if the user didn't have to duplicate this action? What if the user could
> just add this action once, in their `keybindings` or `commands`, and have it
> work both as a keybinding AND a command?
>
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
This is the spec for the Advanced Tab Switcher. This would allow the user to navigate through a vertical list of tabs through a UI, similar to those found in VSCode and Visual Studio.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#1502: Feature Request: Advanced Tab Switcher
#973: Ctrl+Tab toggling between two tabs
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Spec for #1502
* [x] CLA signed.
## Summary of the Pull Request
This PR aims to move the command palette spec out of the draft state and into a finalized state for inclusion in the 2.0 version of the Windows Terminal.
Notably, I've added sections regarding the ability to run `wt` commandlines using the Command Palette UI, something we hadn't considered in the original draft, because `wt` commandlines didn't land for like _4 months_ after this first draft.
## References
* #2046 - the original command palette thread
* #2193 - the original draft PR
* #5400 - the new command palette megathread for WT 2.0, which I'll be updating with follow-up tasks as we work on implementing this.
## PR Checklist
* [x] Specs #2046
* [x] I work here
* [x] Is documentation
## Detailed Description of the Pull Request / Additional comments
_read the spec_
The spec introduces a keybinding argument of 'target' to be able to open a specific settings file. When the Settings UI gets implemented, it will also become an option.
Alternative designs were presented but the 'target' model was decided on.
## Summary of the Pull Request
We have a number of bugs in the Terminal that all have the same singular root cause - VT input does not carry the same fidelity that Win32 input does. For Win32 applications there are certain keystrokes that simply cannot be represented with VT sequences.
This is my proposal for how we'll handle all these cases. I'm proposing a _new VT sequence_, which will enable the Terminal to send input with all of the information that an `INPUT_RECORD` might have, to conpty. There, conpty will be able to send input to the client application with the same fidelity they're used to, enabling these keys to work for those applications once again.
## PR Checklist
* [x] Specs #4999
* [x] I work here
* [x] is a spec
## Detailed Description of the Pull Request / Additional comments
_read the spec_
_This is literally just #1357, but moved to the `drafts/` folder_. Since
@dsafa doesn't have the time to finish this on their own, we'll take it
from here for 2.0 ☺️
## Summary of the Pull Request
Adds a spec describing jumplist integration and adding profiles to the jumplist. Includes details about previous investigations into adding the jumplist.
## PR Checklist
* [x] Specs #576
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [n/a] Tests added/passed
* [x] Requires documentation to be updated
* [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #576
## Detailed Description of the Pull Request / Additional comments
Details in the spec.
## Validation Steps Performed
N/A
Co-authored-by: Brandon Chong <brndnchong@gmail.com>
* Add a spec for the Command Palette
specs #2046.
* Apply suggestions from code review
Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com>
* * Add note from Carlos about UIA
* Add a note about nested commands
* fix Michael's comments
* Move to `doc/specs/`
* Apply suggestions from code review
Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com>
* Add updates from Dustin
esp. considering keybindings args, localization
* add notes about expanding profiles, localization
* move this spec to the drafts folder
Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
Co-authored-by: Dustin L. Howett (MSFT) <duhowett@microsoft.com>
This is the spec that goes into what we do with HTML copy once we set the
default copy behavior to plain text.
Specs #4191
Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
Co-authored-by: Josh Soref <jsoref@users.noreply.github.com>
Co-authored-by: Leon Liang <57155886+leonMSFT@users.noreply.github.com>
This commit introduces a github action to check our spelling and fixes
the following misspelled words so that we come up green.
It also renames TfEditSes to TfEditSession, because Ses is not a word.
currently, excerpt, fallthrough, identified, occurred, propagate,
provided, rendered, resetting, separate, succeeded, successfully,
terminal, transferred, adheres, breaks, combining, preceded,
architecture, populated, previous, setter, visible, window, within,
appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing,
prioritized, aforementioned, check in, build, filling, indices, layout,
mapping, trying, scroll, terabyte, vetoes, viewport, whose
Generated by https://github.com/jsoref/spelling `f`; to maintain your repo, please consider `fchurn`
I generally try to ignore upstream bits. I've accidentally included some items from the `deps/` directory. I expect someone will give me a list of items to drop, I'm happy to drop whole files/directories, or to split the PR into multiple items (E.g. comments/locals/public).
Closes#4294
## Summary of the Pull Request
This is the spec for adding commandline arguments to the Windows Terminal. This includes design work for a powerful future version of the commandline args for the Terminal, as well as a way that system could be implemented during 1.0 to provide basic functionality, while creating commandlines that will work without modification in (a future Windows Terminal version).
## References
Referenced in the course of this spec:
* #607 Feature Request: wt.exe supports command line arguments (profile, command, directory, etc.)
* #1060 Add "open Windows terminal here" into right-click context menu
* #576 Feature Request: Task Bar jumplist should show items from profile
* #1357 Draft spec for adding profiles to the Windows jumplist
* #2080 Spec for tab tear off and default app
* #632 [Question] Configuring Windows Terminal profile to always launch elevated
* #2068 New window key binding not working
## PR Checklist
* [x] Specs #607
* [x] I work here
* [x] _it's a spec_
## Detailed Description of the Pull Request / Additional comments
Read the spec.
-----------------------------------------------------
* Let's commit this bewfore I go hog-wild on new-window
* new-window vs new-tab discussion
* Well, this is ready for a review
* -P -> -% for --percent
* Big note on powershell
of course, powershell has to use `;` as the command seperator
* Minor typos
* This is a lot of feedback from PR
bigly, it's focus-pane and focus-tab
* Add notes on implementation, based on investigation
* Apply suggestions from @miniksa
* some updates after actually implementing the thing
* some minor things from PR
* Apply suggestions from code review
Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com>
* comments from dustin's latest review
* more comments from dustin
* mostly just typos
Co-authored-by: Dustin L. Howett (MSFT) <duhowett@microsoft.com>
Refer to the original issue: **Default Profile for Common Profile Settings** #2325
So this is my summary of everything we discussed regarding "default profile settings". The original PR was #3369, but we were _not_ in agreement on the UX, so this PR is for discussion about that.
I put forth 4 proposals that were mentioned in the discussion.
In the discussion that followed, we decided the 3rd proposal was the best. The doc reflects that choice.
* First draft of a spec for splitting off the existing VT52 escape sequences, and extending the VT52 support.
* Make the issue ID visible on GitHub.
* Added suggested mappings for the Graphics Mode character set.
* Add escape sequences for all the commands and clarify the use of the ESC < sequence when switching back to ANSI mode.
* Add details about the differing boundary rules of the VT100 CUP command and the VT52 Direct Cursor Address command.
* Specify the identifying sequence that the Identify command should return.
* Add details of the print commands.
* Add a list of keyboard sequences that are different in the VT52 mode, and make the description of the Keypad Mode commands a little clearer.
* Add a section describing the testing needed to cover the new functionality.
Submitting first draft of spec template, and `contributing.md` outlining our guidance on how to engage with us, file issues, suggest features, submit changes, etc.