terminal/.github/actions/spelling/expect/web.txt

http
td
www
ecma
rapidtables
WCAG
freedesktop
ycombinator
robertelder
kovidgoyal
leonerd
fixterms
uk
winui
appshellintegration
gfycat
what3words
ci: run spell check in CI, fix remaining issues (#4799) 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 2020-03-25 19:02:53 +01:00			`http`
			`td`
			`www`
ci/spelling: add ecma to the allowlist (#5275) 2020-04-07 23:39:21 +02:00			`ecma`
Add support for setting a tab's color at runtime w/ context menu (#3789) This commit introduces a context menu for Tab and a new item, "Color...", which will display a color picker. A flyout menu, containing a custom flyout, is attached to each tab. The flyout displays a palette of 16 preset colors and includes a color picker. When the user selects or clears color, an event is fired, which is intercepted by the tab to which the flyout belongs. The changing of the color is achieved by putting the selected color in the resource dictionary of the tab, using well-defined dictionary keys (e.g. TabViewItemHeaderBackground). Afterwards the visual state of the tab is toggled, so that the color change is visible immediately. Custom-colored tabs will be desaturated (somewhat) by alpha blending them with the tab bar background. The flyout menu also contains a 'Close' flyout item. ## Validation Steps Performed I've validated the behavior manually: start the program via the start menu. Right click on the tab -> Choose a tab color. The color flyout is going to be shown. Click a color swatch or click 'Select a custom color' to use the color picker. Use the 'Clear the current color' to remove the custom color. Closes #2994. References #3327. 2020-05-04 22:57:12 +02:00			`rapidtables`
Fix a few minor typos from #3789 (#5740) I never got to fixing these in the original #3789 PR, but I messed up that branch way too many times already that I figured I'd just do it in post. * [x] Fixes the typo bot in `master` * [x] I work here 2020-05-04 23:47:29 +02:00			`WCAG`
Spec for Improved keyboard handling in Conpty (#5887) ## 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_ 2020-06-04 14:42:33 +02:00			`freedesktop`
			`ycombinator`
			`robertelder`
			`kovidgoyal`
			`leonerd`
			`fixterms`
			`uk`
Add a context menu entry to "Open Windows Terminal here" (#6100) ## Summary of the Pull Request ![image](https://user-images.githubusercontent.com/18356694/82586680-94447680-9b5d-11ea-9cf1-a85d2b32db10.png) I went with the simple option - just open the Terminal with the default profile in the selected directory. I'd love to add another entry for "Open Terminal here with Profile...", but that's going to be follow-up work, once we sort out pulling the Terminal Settings into their own dll. ## References * I'm going to need to file a bunch of follow-ups on this one. - We should add another entry to let the user select which profile - We should add the icon - I've got to do it in `dllname.dll,1` format, which is annoying. - These strings should be localized. - Should this only appear on <kbd>Shift</kbd>+right click? Probably! However, I don't know how to do that. * [A Win7 Explorer Command Sample](https://github.com/microsoft/Windows-classic-samples/tree/master/Samples/Win7Samples/winui/shell/appshellintegration/ExplorerCommandVerb) which hasn't aged well * [cppwinrt tutorial](https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/author-coclasses) on using COM in cppwinrt * [This is PowerToys' manifest](https://github.com/microsoft/PowerToys/blob/d2a60c7287eb5667b5282a519c92b759664c9e30/installer/MSIX/appxmanifest.xml#L53-L65) and then [their implementation](https://github.com/microsoft/PowerToys/blob/d16ebba9e0f06e7a0d41d981aeb1fd0a78192dc0/src/modules/powerrename/dll/PowerRenameExt.cpp) which were both helpful * [This ](https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-extensions#instructions) was the sample I followed for how to actually set up the manifest, with the added magic that [`desktop5` lets you specify "Directory"](https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-desktop5-itemtype) ## PR Checklist * [x] Closes #1060 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments This adds a COM class that implements `IExplorerCommand`, which is what lets us populate the context menu entry. We expose that type through a new DLL that is simply responsible for the shell extension, so that explorer doesn't need to load the entire Terminal just to populate that entry. The COM class is tied to the application through some new entries in the manifest. The Clsid values are IMPORTANT - they must match the UUID of the implementation type. However, the `Verb` in the manifest didn't seem important. 2020-05-28 17:42:13 +02:00			`winui`
			`appshellintegration`
Spec for Windows Terminal Window Management (#8135) ### ⇒ [doc link](https://github.com/microsoft/terminal/blob/dev/migrie/s/4472-window-management/doc/specs/%235000%20-%20Process%20Model%202.0/%234472%20-%20Windows%20Terminal%20Session%20Management.md) ⇐ ## Summary of the Pull Request This is a more detailed spec for two parts of the "Process Model 2.0" work that's being tracked in #5000. In particular, this spec focuses on the management of Windows Terminal windows, including opening new tabs in existing windows. Largely, the reader is expected to have already read the spec in progress in #7240, and already be familiar with the concept of "Monarch" and "Peasant" windows as introduced by that spec. For that reason, ⚠ THIS PR IS TARGETING THE BRANCH FOR #7240 ⚠. ### Abstract > This document is intended to serve as an addition to the [Process Model 2.0 > Spec]. That document provides a big-picture overview of changes to the entirety > of the Windows Terminal process architecture, including both the split of > window/content processes, as well as the introduction of monarch/peasant > processes. The focus of that document was to identify solutions to a set of > scenarios that were closely intertwined, and establish these solutions would > work together, without preventing any one scenario from working. What that > document did not do was prescribe specific solutions to the given scenarios. > > This document offers a deeper dive on a subset of the issues in [#5000], to > describe specifics for managing multiple windows with the Windows Terminal. This > includes features such as: > > * Run `wt` in the current window ([#4472]) > * Single Instance Mode ([#2227]) ## PR Checklist * [x] Specs: #4472, Specs #2227 * [x] References: #5000, #4472, #2227, #7240 * [x] I work here ## Detailed Description of the Pull Request / Additional comments _\<sup>\</sup><sub>\</sub> read the spec <sub>\</sub><sup>\</sup>\_ ### Why are these two separate documents? I felt that the spec that is currently in review in #7240 and this doc should remain separate, yet closely related documents. #7240 is more about showing how this large set of problems discussed in #5000 can all be solved technically, and how those solutions can be used together. It establishes that none of the proposed solutions for components of #5000 will preclude the possibility of other components being solved. What it does _not_ do however is drill too deeply on the user experience that will be built on top of those architectural changes. This doc on the other hand focuses more closely on a pair of scenarios, and establishes how those scenarios will work technically, and how they'll be exposed to the user. ### TODO: * [x] A thought - How will we handle arguments like `--fullscreen`, `--initialSize r,c`? They only apply when creating a new window, right? * [x] When a `wt -s 1 split-pane` command is executed, we'll need to make sure to not _also_ create a new tab 2021-02-05 13:30:02 +01:00			`gfycat`
			`what3words`