From a9d57ef9ea4a3fe2f2ef611a76b2da0be0d9d51c Mon Sep 17 00:00:00 2001 From: paul cheung Date: Tue, 24 Sep 2019 10:58:02 +0800 Subject: [PATCH] doc: minor typo fix (#2860) --- doc/cascadia/Keybindings-spec.md | 2 +- doc/virtual-dtors.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/cascadia/Keybindings-spec.md b/doc/cascadia/Keybindings-spec.md index e4cbd36a48..a3ee563722 100644 --- a/doc/cascadia/Keybindings-spec.md +++ b/doc/cascadia/Keybindings-spec.md @@ -6,7 +6,7 @@ ## Abstract It should be possible to configure the terminal so that it doesn't send certain keystrokes as input to the terminal, and instead triggers certain actions. Examples of these actions could be copy/pasting text, opening a new tab, or changing the font size. -This spec describes a mechanism by which we could provide a common implementation of handling keyboard shortcuts like these. This common implementation could then be leveraged and extended by the UX implementation as to handle certain callbacks in the UX layer. For example, The TerminalCore doesn't have a concept of what a tab is, but the keymap abstraction could raise an event such that a WPF app could implement creating a new tab in its idomatic way, and UWP could implement them in their own way. +This spec describes a mechanism by which we could provide a common implementation of handling keyboard shortcuts like these. This common implementation could then be leveraged and extended by the UX implementation as to handle certain callbacks in the UX layer. For example, The TerminalCore doesn't have a concept of what a tab is, but the keymap abstraction could raise an event such that a WPF app could implement creating a new tab in its idiomatic way, and UWP could implement them in their own way. ## Terminology * **Key Chord**: This is any possible keystroke that a user can input diff --git a/doc/virtual-dtors.md b/doc/virtual-dtors.md index 1cb70cc1f2..331ddd0fca 100644 --- a/doc/virtual-dtors.md +++ b/doc/virtual-dtors.md @@ -27,7 +27,7 @@ You may ask yourself, why is the destructor deleted, then later defined to the strangeness that can occur as well, the details of which escape my memory from when @austdi and I first investigaved this early 2018. -The end result of not defining your interfaces exacly like this will be that +The end result of not defining your interfaces exactly like this will be that occasionally, when destructing objects, you'll get a segfault. To check that this behavior works, I direct your attention to the VtIoTests.