This corrects the path to `Terminal.Core.Unit.Tests.dll` in the `runut`
unit test script and makes the `runft` feature test script capable of
working with _Release_ builds as well as _Debug_ builds.
The path to `Terminal.Core.Unit.Tests.dll` changed when the project was
restructured, and the `runut` script was never updated to reflect that
change. That has now been corrected.
And the `runft` script used to be hard coded to look for tests in the
_Debug_ directory, but it has now been updated to use the
`%_LAST_BUILD_CONF%` environment variable, so it should work for both
_Debug_ and _Release_ builds.
## Validation Steps Performed
I've manually confirmed that the `runut` and `runft` scripts now work as
expected.
Closes#8485
This PR improves the clipboard handling logic of "drag and drop" in
TermControl, making it more useful and less likely to crash.
* Added support for two more categories of content, `ApplicationLink`
and `WebLink`.
* Reordered the ifs, making `StorageItem` the last clause. With WT being
a text-oriented application, I think we can safely assume that the
content being pasted is likely to be text/links.
* Catch possible exceptions during
`e.DataView().GetStorageItemsAsync()`.
Closes#7804
`backgroundImageAlignment` is exposed as 1 setting in the JSON, but
stored as two separate settings (`HorizontalAlignment` and
`VerticalAlignment`). This PR introduces `ConvergedAlignment` as a flag
enum that can be a combination of horizontal and vertical Alignments.
TSM now solely uses this `ConvergedAlignment`, and TerminalSettings
performs a conversion from this new enum to the traditional
`HorizontalAlignment` and `VerticalAlignment` for consumption.
## Validation Steps Performed
Manually tested changing the `backgroundImageAlignment` in my
settings.json and checking if the image updated appropriately.
Show a validation warning when someone sets a `setColorScheme` action
with an invalid scheme
In the setting validation phase, scan all commands for all the "set
color scheme" actions, and check each of them has a valid scheme. If any
of them has an invalid scheme name, raise a warning. Do not check
iterable commands that will be expanded to valid color schemes.
## Validation Steps Performed
- Added tests to LocalTests_SettingsModel
- Manual tests, add commands to settings.json with invalid color scheme
and check the warning pops up. Try simple and nested commands.
Closes#7221
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/8421
* [x] CLA signed.
* [x] Tests added/passed
## Detailed Description of the Pull Request / Additional comments
Skip further computations if:
* The list is empty
* No item is selected and we press "up" key
(we do want to handle "down" key for CommandLineMode)
## Validation Steps Performed
* Manual testing + UT
## Summary of the Pull Request
I think we all agree that the current spec template doesn't always work. I
thought this layout might be better for the kinds of settings discussions we
have (more and more frequently now).
This is largely for discussion with the team - if there are other things we want
added, changed, or if we just want to merge this in with the primary spec
template, I'm all ears.
## References
* An example of using this spec: #8375
The Settings UI exposes the `profiles.defaults` (PD) object. Today, we
remove PD if there's nothing in it. However, that causes problems with
the Settings UI, because we have no `Profile` object to bind to
(resulting in a crash). Rather than making the Settings UI create a PD,
and link it in the inheritance tree, it's much easier to just _always_
create and link the PD object.
## References
#1564 - Settings UI (fixes a crash for this)
#7923 - Introduces inheritance
## PR Checklist
* [X] Tests added/passed
## Validation Steps Performed
* [x] repro steps for crash in Settings UI (copied changes over to that
branch for testing)
* [x] tests passed
This fixes the issue with the settings UI where clicking the browse
buttons would cause an exception to be thrown when we tried to display a
picker without an originating HWND.
It turns out that pickers need a hosting/parent window, and Xaml Islands
doesn't furnish us with a CoreWindow that's set up for that use case.
Alas!
Raymond Chen's [blog post on the matter] suggests that we should
hand the HWND off through some classic COM interface. To do that
properly, Terminal's various components need to implement that interface
and propagate the HWND down where it's needed.
Thanks to a [Xaml compiler issue], we can't actually do that. To work
around that, we've begged and borrowed different methods for pushing
HWNDs around:
1. Using IInitializeWithWindow in secret
2. A member that takes a uint64
3. An interface that offers a function that will "wire up" the HWND.
I chose (1) because AppHost can implement IInitializeWithWindow, but
TerminalPage cannot. We're just pretending that TerminalPage _can_.
I chose (2) because none of the Xaml types in TerminalSettingsEditor can
implement the interface thanks to the aforementioned compiler issue, but
we don't have an escape hatch like AppHost that lives in the same module
and can help us do the propagation.
I chose (3) because I didn't want to commit the same sin as (2) _seven
times_ for every different type of settings page that exists. (3) is
backed by "IHostedInWindow", and anybody who knows they have to use
IInitializeWithWindow to tie an HWND to an object can call
IHostedInWindow.TryPropagateHostingWindow() on that object.
House of cards.
[Xaml compiler issue]: https://github.com/microsoft/microsoft-ui-xaml/issues/3331
[blog post on the matter]: https://devblogs.microsoft.com/oldnewthing/20190412-00/?p=102413
(cherry picked from commit f9fc9861a1)
When the viewport is moved to the "virtual bottom" of the buffer (via
the `MoveToBottom` method), it is important that the horizontal viewport
offset be left as it is, otherwise that can result in some undesirable
side effects.
Since the VT coordinate system is relative to the top of the viewport,
many VT operations call the `MoveToBottom` method to make sure the
viewport is correctly positioned before proceeding. There is no need for
the horizontal position to be adjusted, though, since the X coordinates
are not constrained by the viewport, but are instead relative to the
underlying buffer.
Setting the viewport X coordinate to 0 in `MoveToBottom` (as we were
previously doing) could result in the cursor being pushed off screen.
And if the operation itself was moving the cursor, that would then
trigger another viewport move to bring the cursor back into view. These
conflicting movements meant the viewport was always forced as far left
as possible, and could also result in cursor "droppings" as the cursor
lost track of where it had been.
I've now fixed this by updating the `GetVirtualViewport` method to match
the horizontal offset of the active viewport, instead of having the X
coordinate hardcoded to 0.
## Validation Steps Performed
I've manually confirmed that this fixes the cursor "droppings" test case
reported in issue #8213.
I've also added a screen buffer test that makes sure the `MoveToBottom`
method is working as expected, and not changing the horizontal viewport
offset when it moves down.
Closes#8213
If we try set a very long title, "rename box" UI changes max height,
corrupting the layout. There are several ways to fix it, e.g. by
limiting the MaxHeight (e.g. by binding it to the actual height of the
title bar).
However, I went for the most straightforward approach - truncating. I
don't think we should allow long titles (though it can be a nice hidden
storage 😊)
I considered to truncate it to the tab header width, but we can actually
see more data in tab-switcher, so I simply went for a hard-coded value
which should be large enough.
If this approach makes sense we need to consider updating the
documentation.
Closes#8428
We had the xterm and SGR codings for meta/ctrl backwards. Oops.
This commit also fixes an observed issue in Windows Terminal where we
were passing in a console-style modifiers enum when MouseInput is
expecting MK_ constants.
I decided to unify MouseInput around the console-style modifier
constants because they have support for META (which MK_ does not) and
can differentiate between left/right alt/ctrl.
Our tests are fundamentally flawed here: they use a copy of the
modifier key generating logic _themselves_, so we got a bit of "error
carried forward."
I did not fix the tests to use known-good control sequences, I simply
replaced the character generator with another copy of the modifier code.
I did, however, extend them to test ctrl|meta and left/right modifiers.
Fixes#8291
Fix for #8365
Adds a `_renameCancelled` bool that determines whether we raise the event for a title change. We do this because the lost focus handler for the rename box will be called _both_ when the renamer is dismissed by clicking somewhere else and by pressing enter/escape. So, the lost focus handler needs to conditionally raise the event.
Closes#8365
## Summary of the Pull Request
Introduces a new command called `moveTab`
This command has a single mandatory argument with values of `forward` and `backward`
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/3593
* [x] CLA signed.
* [x] Tests added/passed
* [x] Documentation updated here: https://github.com/MicrosoftDocs/terminal/pull/198
* [x] Schema updated
* [x] I've discussed this with core contributors already.
## Detailed Description of the Pull Request / Additional comments
Went for the straightforward solution of moving the tab and the tabViewItem.
## Validation Steps Performed
* Manual testing
Many include statements use forward slashes, while others use backwards
slashes. This is inconsistent formatting. For this reason, I changed the
backward slashes to forward slashes since that is the standard.
## Summary of the Pull Request
Add a history to command palette in the command line mode.
Few considerations/limitations
1. In-memory, 10 entries hard-coded
2. MRU
3. List rather than set
4. The user needs explicitly select command from the history
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/8296
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Documentation updated - irrelevant
* [ ] Schema updated - irrelevant
* [ ] I've discussed this with core contributors already.
## Validation Steps Performed
* Manual testing
The CloseWarningDialog is now "awaitable"/async, as suggested in PR #7871.
As opening the dialog is async, the flag can be reset in the same
method. This way the flag operations occur in the same method. The
event handlers of the buttons became obsolete and are removed.
## Validation Steps Performed
Tested manually.
## Summary of the Pull Request
Does what the title says. Now while you're building terminal projects,
the taskbar will show indeterminate progress. If the build fails, it'll
blink the error state for 500ms before returning to normal.
## References
* Made possible by #8055 _and viewers like you_
## PR Checklist
* [x] scratches an itch I've had since at least 2018
* [x] I work here
* [x] this is a build script
## Validation Steps Performed
tested manually
* Add a tabColor parameter to the `new-tab` and `split-panes` command
* Add --tabColor to the command line, to allow bootstrapping with tabs
of different colors
Add another field to NewTerminalArgs. Use this field to set
StartingTabColor in Terminal. This color gets overridden by the color
defined by the profile / VT, however can be overridden with the color
picker.
Since the color is the property of the Terminal, when defined for the
tab this color is associated only with the first pane/terminal of the
tab. Additional panes will not inherit this color (to prevent advanced
resolution, where we need to resolve between the inherited color and the
one specified for the pane).
## Validation Steps Performed
* UT for parameters parsing
* Running system with several tabs of different colors.
* Adding custom actions with colors
* Performing operations like split pane, duplicate and so on
Closes#8075
One of our test files has some raw Emoji in it. I expect that as time
goes by, more and more files will have UTF-8 in them.
Fixes MSFT-30289536
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_onecore_dep_uxp d828ae0f6c209259019934711c587ea075eab77e
[Git2Git] Git Train: Merge of building/rs_onecore_dep_uxp/201117-2002 into official/rs_onecore_dep_uxp Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_onecore_dep_uxp 526043ab6050397506b3cdb77e6a43b5ca9a2e9a
Related work items: MSFT-29990377
The terminal taskbar icon can now flash when the BEL sequence is
emitted, to let the user know something needs their attention.
The `BellStyle` setting can now be set to `audible`, `visual` or both or
none. When the pane receives a BEL event and the `bellStyle` includes
`visual`, we bubble the event up all the way to `AppHost` to handle
flashing the taskbar.
Closes#1608
This commit implements the OSC 9;4 sequence per the [ConEmu style].
| sequence | description |
| ------------ | ------------ |
| `ESC ] 9 ; 4 ; st ; pr ST` | Set progress state on taskbar and tab. |
| | When `st` is: |
| | |
| | `0`: remove progress. |
| | `1`: set progress value to `pr` (number, 0-100). |
| | `2`: set the taskbar to the "Error" state |
| | `3`: set the taskbar to the "Indeterminate" state |
| | `4`: set the taskbar to the "Warning" state |
We've also extended this with:
* st 3: set indeterminate state
* st 4: set paused state
We handle multiple tabs sending the sequence by using the the last focused
control's taskbar state/progress.
Upon receiving the sequence in `TerminalApi`, we send an event that gets caught
by `TerminalPage`. `TerminalPage` then fires another event that gets caught by
`AppHost` and that's where we set the taskbar progress.
Closes#3004
[ConEmu style]: https://conemu.github.io/en/AnsiEscapeCodes.html#ConEmu_specific_OSC
Currently when implicit tab command is specified (i.e., we have
parameters for new-tab, but don't have the explicit subcommand name) we
fallback to parsing the entire arg list as new tab command.
However, if we also have a launch profile (or anything else that might in
the future belong to the upper scope) it is passed as a parameter to the
new tab command, failing the parsing.
The idea behind my solution is to run the parser as a prefix command -
i.e., as long as we succeed to parse [options] / [subcommand] we will
parse them (populating the fields like a launch mode), but once we will
discover something unfamiliar, like profile, we will know that the
prefix is over and will handle the remaining suffix as a new tab
command.
## Validation Steps Performed
* UT added
* Manual run of different options
Closes#7318
<!-- 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 sets the tab close button color to match the tab text color.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#8046
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#8046
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] 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: #8046
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
This sets the tab close button color to match the tab text color.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Test light theme white tab mouse hover effect:
![Screenshot_2020-11-07_152110_3](https://user-images.githubusercontent.com/7143383/98640319-ec735e80-22de-11eb-8d35-08188405b566.png)
Test dark theme white tab mouse hover effect:
![Screenshot_2020-11-07_153021_2](https://user-images.githubusercontent.com/7143383/98640377-f006e580-22de-11eb-9bb5-dde9fe9b81b6.png)
This fixes a number of exceptions that can cause conhost to crash when
the buffer is resized in such a way that the viewport or cursor position
end up out of bounds.
Technically this is a fix for issue #256, although that has been closed
as "needs-repro".
The main fix was to add checks in the `SetConsoleScreenBufferSizeImpl`
and `SetConsoleScreenBufferInfoExImpl` methods, to make sure the
viewport doesn't extend past the bottom or right of the buffer after a
resize. If it has overflowed, we move the viewport back up or left until
it's back within the buffer boundaries. We also check if the cursor
position has ended up out of bounds, and if so, clamp it back inside the
buffer.
The `SCREEN_INFORMATION::SetViewport` was also a source of viewport
overflow problems, because it was mistakenly using inclusive coordinates
in its range checks, which resulted in them being off by one. That has
now been corrected to use exclusive coordinates.
Finally, the `IsCursorDoubleWidth` method was incorrectly marked as
`noexcept`, which was preventing its exceptions from being caught.
Ideally it shouldn't be throwing exceptions at all any more, but I've
removed the `noexcept` specifier, so if it does throw an exception,
it'll at least have more chance of recovering without a crash.
## Validation Steps Performed
I put together a few test cases (based on the reports in issues #276 and
#1976) which consistently caused conhost to crash, or to generate an
exception visible in the debug output. With this PR applied, those test
cases are no longer crashing or triggering exceptions.
Closes#1976
## Summary of the Pull Request
This adds `ToJson` functions to `Profile`, `GlobalAppSettings`, and `ColorScheme`. They are used in `CascadiaSettings` to completely serialize an instance of the settings model. Thanks to #7923, all of the settings are `std::optional`, and `JsonUtils` only writes out values that are actually populated.
`CascadiaSettings::WriteSettingsToDisk` serializes the current settings and writes them to the settings.json. A backup file is created with your old contents.
#### Limitations:
- all of the color schemes are serialized regardless of them coming from defaults.json or settings.json
- keybindings/actions are copied/pasted
## References
#1564 - Settings UI
TSM Specs (#6904 and #7876)
## PR Checklist
* [x] Tests added/passed
Fixes the clear button to clear the typed command not clickable in the
command palette.
- From the primary investigation it looked like the `TextBlock` element
introduced in #7935 was somehow blocking (appearing on top of) the
clear button.
- It was also blocking the command palette input field from being able
to access which was preventing the text in the input field from being
selected and the cursor would still show as `pointer` cursor instead
of a `text selection` cursor
- Adding `HorizontalAlignment="Left"` property to the above-mentioned
`TextBlock` element fixed the issue.
## Validation Steps Performed
- Created the Dev build for `x64` in Visual Studio and verified the
functionality manually.
Closes#8220
Some sources files changes were necessary to retain build continuity in OS.
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_onecore_dep_uxp 7ff895ff770838526b6d1d9e7d582f3c1e36d85b
Fixes https parsing of the latest version of `profiles.schema.json`, particularly by VS Code Intellisense.
* [x] Closes#8249
The VS Code parsing warning below is a known and unrelated existing issue due to VS Code only supporting JSON Schema Draft 7. It does not prevent Intellisense from functioning.
> Draft 2019-09 schemas are not yet fully supported.
## Validation Steps Performed
Manually tested and successfully validated by fixing a local copy of `profiles.schema.json` and defining it as `$schema` in `settings.json`
conhost and windows terminal
renamed files; updated script to do summary output only, also quiet mode and option file path for output (else stdout)
added -quiet and fixed -summaryonly parameters
added hyperlink directly to soruce implementation for conhost and terminal seqs
Update doc/reference/master-sequence-list.csv
Co-Authored-By: James Holderness <j4_james@hotmail.com>
Apply suggestions from code review
Co-Authored-By: James Holderness <j4_james@hotmail.com>
Co-authored-by: James Holderness <j4_james@hotmail.com>
Until now, we relied on WM_SIZING to ensure that the island is not
downsized below minimal allowed dimensions. However, on some occasions
WM_WINDOWPOSCHANGED, e.g. when anchoring a window to the top/bottom of
the screen. This message will use dimensions obtained from
WM_GETMINMAXINFO. Until now we didn't override this value, falling back
to the defaults. As a result we got an inconsistent behavior (at least
when attaching the anchor).
I added logic very similar to the one we use in IslandWindow::_OnSizing
to the MINMAXINFO handler: snap the client area, add non client
exclusive are, consider DPI along the computation.
## Validation Steps Performed
* Manual testing of minimizing, maximizing, resizing, attaching
different anchors, etc.
Closes#8026
There are two code paths for Ctrl+Tab and for everything else:
Ctrl + Tab is working perfectly
* On the first tab navigation TerminalPage::_SelectNextTab resets the
tab commands, and since palette is not visible selects the relevant
tab index
* On the second navigation Ctrl+Tab is intercepted by
CommandPalette::_previewKeyDownHandler and everything works fine
But with custom binding things are screwed:
* On the first tab navigation TerminalPage::_SelectNextTab resets the
tab commands, and since palette is not visible selects the relevant
tab index
* On the second navigation keys are not intercepted and thus
TerminalPage::_SelectNextTab is called again. It resets the commands,
but now since the palette is visible we simply invoke
CommandPalette::SelectNextItem. Which in turn misbehaves because no
item is selected.
The approach for the solution is not to reset anything if the command
palette is already open.
## Validation Steps Performed
* Manual testing of both custom and non-custom bindings with different
amount of tabs.
Closes#8247
* Run all images through ImgBot (CC-8169)
* Fix potential over/underflow as noted by "TODO:" comment (CC-8081)
* Fix garbling when copying multibyte text via OSC 52 (CC-7870)
* UIA: throw E_FAIL for out-of-bounds text (CC-8052)
* Consider the GlyphWidth when calculate the postion of matched word in URL detecting (CC-8124)
* Make the link underline less obtrusive; don't use it for pattern (GH-8148)
* Fully regenerate CodepointWidthDetector from Unicode 13.0 (GH-8035)
* Prepare for the primary branch name to change to main (GH-7985)
* Hash the URI as part of the hyperlink ID (GH-7940)
* Introduce til::presorted_static_map (GH-7640)
* Prevent leftover cursor fragments when scrolling in PowerShell (CC-8173)
* Add support for the DECREQTPARM report (CC-7939)
* Refactor VT parameter handling (CC-7799)
* Add support for the "blink" graphic rendition attribute (CC-7490)
* Combine the parsing & dispatch blocks for OSC actions (CC-8202)
* Add support for autodetecting URLs and making hyperlinks (CC-7691)
* Copy _currentHyperlinkId when copying the buffer (CC-8074)
* Fix the "visual representation" optimization for hyperlinks (CC-7738)
* Optimize the binary size of the XOrg color table (CC-7929)
* Add support for more OSC color formats (CC-7578)
Related work items: MSFT-30259074
In `ActionOscDispatch()` in `OutputStateMachineEngine.cpp`, we had a
section for parsing and another section for dispatching. This PR
combines those two blocks since they do not need to be distinct.
## Validation Steps Performed
TerminalApiTests still pass