* Merge pane splitting methods
Having separate Horizontal/Vertical versions made it hard to manage, and App.cpp already made use of Pane::SplitState so it made sense to have that be the descriminator
* Rename Tab::(Can)AddSplit to (Can)SplitPane to align with Pane methods
Split was used as a noun in Tab but a verb in Pane, which felt odd
* Remove unused local variable in Pane::_CanSplit
* Remove redundant 'else' branches in Pane
Improves readibility for all 'low hanging fruit' cases where the 'if' was returning.
When the scrollback buffer is empty, the RIS escape sequence (Reset to Initial
State) will fail to clear the screen, or reset any of the state. And when there
is something in the scrollback, it doesn't get cleared completely, and the
screen may get filled with the wrong background color (it should use the
default color, but it actually uses the previously active background color).
This commit attempts to fix those issues.
The initial failure is caused by the `SCREEN_INFORMATION::WriteRect` method
throwing an exception when passed an empty viewport. And the reason it's passed
an empty viewport is because that's what the `Viewport::Subtract` method
returns when the result of the subtraction is nothing. The PR fixes the
problem by making the `Viewport::Subtract` method actually return nothing in
that situation.
This is a change in the defined behavior that also required the associated
viewport tests to be updated. However, it does seem a sensible change, since
the `Subtract` method never returns empty viewports under any other
circumstances. And the only place the method seems to be used is in the
`ScrollRegion` implementation, where the previous behavior is guaranteed to
throw an exception.
The other issues are fixed simply by changing the order in which things are
reset in the `AdaptDispatch::HardReset` method. The call to `SoftReset` needed
to be made first, so that the SGR attributes would be reset before the screen
was cleared, thus making sure that the default background color would be used.
And the screen needed to be cleared before the scrollback was erased, otherwise
the last view of the screen would be retained in the scrollback buffer.
These changes also required existing adapter tests to be updated, but not
because of a change in the expected behaviour. It's just that certain tests
relied on the `SoftReset` happening later in the order, so weren't expecting it
to be called if say the scrollback erase had failed. It doesn't seem like the
tests were deliberately trying to verify that the SoftReset _hadn't_ been
called.
In addition to the updates to existing tests, this PR also add a new screen
buffer test which verifies the display and scrollback are correctly cleared
under the conditions that were previously failing.
Fixes#2307.
On occasion, in certain delegated access scenarios, we'll fail to read
the name of one or more of the user's Azure tenants. We would summarily
explode (because we're being strict about our incoming JSON, and we
didn't know that this was possible.)
Now we'll substitute in an alternate name and present the ID.
Fixes#2249.
* Update src/cascadia/TerminalConnection/AzureConnection.cpp
When we change the client ID, we're going to need to force people to log
in again.
We can do that either by:
1. Trying to log in and refresh the user's token and failing (displaying
a cryptic message like "you aren't on the internet, please get on the
internet"), **OR** by...
2. Getting out ahead of it, detecting when we would have failed for client
ID (and other) reasons, and _not trying at all._
This is option 2.
Refactors the accessibility providers (ScreenInfoUiaProvider and UiaTextRange) into a better separated model between ConHost and Windows Terminal.
ScreenInfoUiaProviderBase and UiaTextRangeBase are introduced. ConHost and Windows Terminal implement their own versions of ScreenInfoUiaProvider and UiaTextRange that inherit from their respective base classes.
WindowsTerminal's ScreenInfoUiaProvider --> TermControlUiaProvider
Since we're rendering with antialiasing enabled, we need to make sure
we're stroking actual pixels; to do that, we need to adjust all of our
coordinates by the StrokeWidth / 2. We're always using a stroke width of
1, so that means 0.5.
While I was here, I took the opportunity to fix the color of the grid
lines. Fixes#543.
This is more trouble than it's worth. We had code before to re-serialize
settings when they changed, to try and gracefully migrate settings from old
schemas to new ones. This is good in theory, but with #754 coming soon, this
is going to become a minefield. In the future we'll just always be providing a
base schema that's reasonable, so this won't matter so much. Keys that users
have that aren't understood will just be ignored, and that's _fine_.
Fixes a crash that can occur when splitting pane that was so small that the target panes would have a width/height of 0, causing DxRenderer to fail when creating the device resources.
This PR prevents both the call to `App::AddHorizontal/VerticalSplit` and the creation of the `TermControl` if the split would fail.
Closes#2401
## Details
`App::_SplitPane` calls `focusedTab->CanAddHorizontalSplit/CanAddHorizontalSplit` before it initializes the `TermControl` to avoid having to deal with the cleanup. If a split cannot occur, it will simply return.
**Question: Should we beep or something here?**
It then follows the same naming/flow style as the split operation, so: `Tab::CanAddHorizontalSplit -> Pane::CanSplitHorizontal ->Pane::_CanSplit`. The public pane methods will handle leaf/child the same as the current Split methods.
`_CanSplit` reuses existing logic like `_root.GetActualWidth/Height`, `Pane::_GetMinSize`, and the `Half` constant.
## Validation Steps Performed
1. Open a new tab
2. Attempt to split horizontally/vertically more than 6-8 times
Success: Pane will will eventually stop splitting rather than crashing the process.
* Start working on drafting this spec
* Really add a LOT of notes
* More spec updates.
* Remove `hiddenProfiles` in favor of `profile.hidden`
* Add info on how layering will work
* add more powershell core info
* Finish remaining TODO sections
* Apply suggestions from code review
Fix simple typos
Co-Authored-By: Dustin L. Howett (MSFT) <duhowett@microsoft.com>
* Lots of feedback from PR
* Try and make dynamic settings a bit clearer
* more clearly call out serializing only what's different from a default-
constructed `Profile`
* Add more goals
* add a blurb for user-default profile objects
* Add updates concerning dynamic profile generation (#1321)
* Add updates concerning dynamic profile generation
This is based on discussion with @dhowett-msft we had o*line. We're trying to
work through a way to prevent dynamic profiles from roaming to machines the
dynamic profiles might not exist on.
After writing this up, I'm not totally sure that it's a better design.
* Add some initial updates from discussion
* Pushing some updates here. I haven't given it a once over to ensure it's all consistent but it's worth reviewing @dhowett-msft
* Some minor updates from Dustin
* Fix a bunch of slightly more minor points in the spec
* Move "Profile Ordering" to "Future considerations"
* Add some notes on migrating profiles, GUID generation, de-duping profiles, and O R A N G E
* Fix the indenting here
* Update powershell core to be a dynamic profile, don't even mention other options.
* Remaining PR feedback
* Apply suggestions from code review
Co-Authored-By: Michael Niksa <miniksa@microsoft.com>
* remove a dead comment
* Move Clipboard::GenHTML to TextBuffer (add params)
Refactor RetrieveSelectedTextFromBuffer
Modify CopyToClipboardEventArgs to include HTML data
* minor code format fix
* PR Changes
NOTE: refactoring text buffer code is a separate task. New issue to be created.
* Refactor TextBuffer::GenHTML (#2038)
Fixes#1846.
* nit change
* x86 build fix
* nit changes
This commit also transitions our keybinding events and event handlers to a
TypedEventHandler model with an "event args" class, as specified in the
keybinding arguments specification (#1349). In short, every event can be marked
Handled independently, and a Handled event will stop bubbling out to the
terminal. An unhandled event will be passed off to the terminal as a standard
keypress.
This unifies our keybinding event model and provides a convenient place for
binding arguments to live.
Fixes#2285.
Related to #1349, #1142.
* Add a spec draft for Keybindings Arguments.
Specs #1142.
Just read the spec :)
* Apply suggestions from code review
Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com>
* Include notes on reliability, security, and `Handle`ing Keybinding Args
* Add some extra details from review
* Split up ActionArgs and ActionEventArgs
* Clarify _not_ handling an action
* Add some notes on parsing args
* Add some future considerations on extensions
* Updating spec to remove the bulk of the `IActionArgs` and `IActionEventArgs` implementations, as they're redundant.
* Warn the user when their settings are bad
The start of work on #1348
* Display an error dialog for errors during validation
* Polish for PR
* Add a ton of tests
* Polish the _GetMessageText bits
* Add code to check for duplicate profiles
* Verify that many warnings work at the same time
* comments y'all
* Apply fixes for dustin's thoughts from PR
* Add a proper exception type, use an array instead of a map
* PR Fixes
* Fix x86 build break
* Add a bit on "using the defaults" when we encountering an exception
* remove a redundant variable
* guid->GUID
* Address Michael's PR comments
* Clean up this error text, and catch exceptions better
* Update src/cascadia/TerminalApp/Resources/en-US/Resources.resw
This commit replaces CodepointWidthDetector's
dynamically-generated map with a static constexpr one that's compiled
into the binary.
It also almost totally removes the notion of an `Invalid` width. We
definitely had gaps in our character coverage where we'd report a
character as invalid, but we'd then flatten that down to `Narrow` when
asked. By combining the not-present state and the narrow state, we get
to save a significant chunk of data.
I've tested this by feeding it all 0x10FFFF codepoints (and then some)
and making sure they 100% match the old code's outputs.
|------------------------------|---------------|----------------|
| Metric | Then | Now |
|------------------------------|---------------|----------------|
| disk space | 56k (`.text`) | 3k (`.rdata`) |
| runtime memory (allocations) | 1088 | 0 |
| runtime memory (bytes) | 51k | ~0 |
| memory behavior | not shared | fully shared |
| lookup time | ~31ns | ~9ns |
| first hit penalty | ~170000ns | 0ns |
| lines of code | 1088 | 285 |
| clarity | extreme | slightly worse |
|------------------------------|---------------|----------------|
I also took a moment and cleaned up a stray boolean that we didn't need.
This seemed like it fit the style & depth of the other Niksa posts, so I'm proposing we add it here. We could always make a `Howett.md` if that seems more reasonable
Double/Triple click create a selection expanding beyond one cell. This PR makes it so that when you're dragging your mouse to expand the selection, you expand to the next delimiter defined by double/triple click.
So, double click expands by doubleClickDelimiter ranges. Triple click expands by line.
When you double/triple click, a word/line is selected. When you drag, that word/line will remain selected after the expansion occurs.
Closes#1933
## Details
Rather than resizing the selection when the mouse event occurs, I figured I'd do what I did with wide glyph selection: expand at render time.
We needed an enum `multiClickSelectionMode` to keep track of which expansion mode we're in.
Minor modifications to `_ExpandDoubleClickSelection*(COORD)` had to be made so that we can re-use them.
Actual expansion occurs in `_GetSelectionRects()`
## Validation Steps Performed
- generic double click test
- `dir` or `ls`
- double click a word
- drag up
- Works! ✔
- double click on delimiter test
- `dir` or `ls`
- double click a word delimiter (i.e.: space between words)
- drag up
- Works! ✔
- generic triple click test
- `dir` or `ls`
- triple click a line
- drag up
- Works! ✔
- ALT + double click test
- `dir` or `ls`
- hold ALT
- double click a word
- drag up
- Works! ✔
repeat above tests in following scenarios:
- when at top of scrollback
- drag down instead of up
### User Stories:
1. A user wants to be able to use the executable path as their starting title
- Does anyone want this?
2. A user wants to be able to set a custom starting title, but have that title be overridable
3. A user wants to be able to set an overridable starting title, different from the profile name
- Presumably someone will want this
4. A user totally wants to ignore the VT title and use something else
- This will make more sense in the post [#1320] "Support runtime variables in the custom user title" settings
### Solutions:
1. `name`, `startingTitle`, `tabTitle`
* a. `name` is only ever used as the profile name.
* b. If `startingTitle` isn't set, then the executable path is used
* c. If `startingTitle` is set, it's used as the initial title
* d. If `tabTitle` is set, it overrides the title from the terminal
* e. Current users of `tabTitle` need to manually update to the new behavior.
2. `name` as starting title, `tabTitle` as a different starting title
* a. `name` is used as the starting title and the profile name in the dropdown
* b. If `tabTitle` is set, we'll use that as the overridable starting title instead.
* c. In the future, `dynamicTabTitle` or `tabTitleOverride` could be added to support [#1320]
* d. Current users of `tabTitle` automatically get the new (different!) behavior.
* e. User Story 1 is impossible
- Does anyone want the behavior _ever_? Perhaps making that scenario impossible is good?
3. `name` unchanged, `tabTitle` as the starting title
* a. `name` is only ever used as the profile name.
* b. If `tabTitle` is set, we'll use that as the overridable starting title.
* c. In the future, `dynamicTabTitle` or `tabTitleOverride` could be added to support [#1320]
* d. Current users of `tabTitle` automatically get the new (different!) behavior.
4. `name` as starting title, `tabTitle` as different starting title, `suppressApplicationTitle` Boolean to force it to override
* a. `name`, `tabTitle` work as in Solution 2.
* b. When someone wants to be able to statically totally override that title (story 4), they can use `suppressApplicationTitle`
* c. `suppressApplicationTitle` name is WIP
* d. We'll add `suppressApplicationTitle` when someone complains
* e. If you really want story 1, use `tabTitle: c:\path\to\foo.exe` and `suppressApplicationTitle`.
[#1320]: https://github.com/microsoft/terminal/issues/1320
We've decided to pursue path 4.
In #1164 we learned that our CI doesn't support WinRT testing. This made us all sad. Since that merged, we haven't really added any TerminalApp tests, because it's a little too hard. You'd have to uncomment the entire file, and if the list of types changed you'd have to manually update the sxs manifest and appxmanifest.
Since that was all insane, I created a new Terminal App unittesting project without those problems.
1. The project is not named *Unit*Test*, so the CI won't run it, but it will run locally.
2. The project will auto-generate its SxS manifest, using the work from #1987.
3. We'll use the SxS manifest from step 2 to generate an AppxManifest for running packaged tests.
* This is the start of me trying to enable local unittesting again
* We've got a new unittests project that isn't named *unit*test*
* We're manually generating the SxS manifest for it. B/C we need to use it at runtime, we need to manually combine it into one manifest file
* the runas:UAP thing still doesn't work. We'll investigate.
* This shockingly works
but I'm still stuck with:
```
Summary of Errors Outside of Tests:
Error: TAEF: [HRESULT: 0x80270254] Failed to create the test host process for
out of process test execution. (The
IApplicationActivationManager::ActivateApplication call failed while using a
default host. TAEF's ETW logs which are gathered with the /enableEtwLogging
switch should contain events from relevant providers that may help to diagnose
the failure.)
```
* Cleaning this all up for review.
Frankly just pushing to see if it'll work in CI
* Couple things I noticed in the diff from master
* Apply @dhowett-msft's suggestions from code review
