starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-08 05:37:27 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

minor typo fix (#2863)

Browse Source
This commit is contained in:
paul cheung
2019-09-25 06:34:26 +08:00
committed by Michael Niksa
parent 9ed9e7c8aa
commit 7faf3342e0
5 changed files with 13 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
doc/cascadia/TerminalSettings-spec.md
View File

@@ -33,7 +33,7 @@ This spec will outline how various terminal frontends will be able to interact w
5. Visual Studio should be able to persist and edit settings globally, without
the need for a globals/profiles structure.
6. The Terminal should be able to read information from a settings structure
that's independant of how it's persisted / implemented by the Application
that's independent of how it's persisted / implemented by the Application
7. The Component should be able to have its own settings independent of the
application that's embedding it, such as font size and face, scrollbar
visibility, etc. These should be settings that are specific to the component,
@@ -79,7 +79,7 @@ Shell Commandline |
### Simple Settings
An application like VS might not even care about settings profiles. They should be able to persist the settings as just a singular entity, and change those as needed, without the additional overhead. Profiles will be something that's more specifc to Project Cascadia.
An application like VS might not even care about settings profiles. They should be able to persist the settings as just a singular entity, and change those as needed, without the additional overhead. Profiles will be something that's more specific to Project Cascadia.
### Interface Descriptions
@@ -228,6 +228,6 @@ I don't like that - if we change the font size, we should just recalculate how m
## Questions / TODO
* How does this interplay with setting properties of the terminal component in XAML?
* I would think that the component would load the XAML properties first, and if the controlling application calls `UpdateSettings` on the component, then those in-XAML properties would likely get overwritten.
* It's not necessary to create the component with a `IComponentSettings`, nor is it necessary to call `UpdateSettings`. If you wanted to create a trivial settings-less terminal component entriely in XAML, go right ahead.
* It's not necessary to create the component with a `IComponentSettings`, nor is it necessary to call `UpdateSettings`. If you wanted to create a trivial settings-less terminal component entirely in XAML, go right ahead.
* Any settings that *are* exposed through XAML properties *should* also be exposed in the component's settings implementation as well.
* Can that be enforced any way? I doubt it.

6
doc/cascadia/Unittesting-CppWinRT-Xaml.md
View File

@@ -82,7 +82,7 @@ project from our `TerminalAppLib` project:
<ItemGroup>
<!-- Manually add references to each of our dependent winmds. Mark them as
private=false and CopyLocalSatelliteAssemblies=false, so that we don't
propogate them upwards (which can make referencing this project result in
propagate them upwards (which can make referencing this project result in
duplicate type definitions)-->
<Reference Include="Microsoft.Terminal.Settings">
@@ -106,7 +106,7 @@ in the dll project's directory.
### Update the dll project
Now that we havea lib that builds all your code, we can go ahead and tear out
Now that we have a lib that builds all your code, we can go ahead and tear out
most of the dead code from the old dll project. Remove all the source files from
the dll's `.vcxproj` file, save for the `pch.h` and `pch.cpp` files. You _may_
need to leave the headers for any C++/WinRT types you've authored in this project
@@ -301,7 +301,7 @@ you want to use any XAML types, then you'll have to keep reading.
### Using Xaml Types (with XAML Islands)
To be able to instatiate XAML types in your unittest, we'll need to make use of
To be able to instantiate XAML types in your unittest, we'll need to make use of
the [XAML Hosting
API](https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/using-the-xaml-hosting-api)
(Xaml Islands). This enables you to use XAML APIs from a Win32 context.

6
doc/specs/#532 - Panes and Split Windows.md
View File

@@ -26,7 +26,7 @@ Windows Terminal.
Panes within the context of a single terminal window are not a new idea. The
design of the panes for the Windows Terminal was heavily inspired by the
application `tmux`, which is a commandline application which acts as a "terminal
multiplexer", allowing for the easy managment of many terminal sessions from a
multiplexer", allowing for the easy management of many terminal sessions from a
single application.
Other applications that include pane-like functionality include (but are not
@@ -115,7 +115,7 @@ We could also split `A` in horizontally, creating a fourth terminal pane `D`.
+---------------+
```
While it may appear that there's a single horizonal separator and a single
While it may appear that there's a single horizontal separator and a single
vertical separator here, that's not actually the case. Due to the tree-like
structure of the pane splitting, the horizontal splits exist only between the
two panes they're splitting. So, the user could move each of the horizontal
@@ -230,5 +230,5 @@ for swapping the positions of tabs, or a shortcut for both "zooming" a tab
tab. Additionally, a right-click menu option could be added to do the
aformentioned actions. Discoverability of these two actions is not as high as
just dragging a tab from one pane to another; however, it's believed that panes
are more of a power-user scenario, and power users will not neccessarily be
are more of a power-user scenario, and power users will not necessarily be
turned off by the feature's discoverability.

6
doc/specs/#754 - Cascading Default Settings.md
View File

@@ -36,7 +36,7 @@ Largely inspired by the settings model that both VS Code (and Sublime Text) use.
### Goal: Minimize Re-Serializing `profiles.json`
We want to re-serialize the user settings file, `profiles.json`, as little as
possible. Each time we serialize the file, there's the possiblity that we've
possible. Each time we serialize the file, there's the possibility that we've
re-ordered the keys, as `jsoncpp` provides no ordering guarantee of the keys.
This isn't great, as each write of the file will randomly re-order the file.
@@ -241,7 +241,7 @@ Currently, these profiles are only generated when a user first launches the
Terminal. If they already have a `profiles.json` file, then we won't run the
auto-generation behavior. This is obviously not great - if any new types of
dynamic profiles are added, then users that already have the Terminal installed
won't get any of these dynamic profiles. Furthemore, if any of the sources of
won't get any of these dynamic profiles. Furthermore, if any of the sources of
these dynamic profiles are removed, then the app won't auto-remove the
associated profile.
@@ -695,7 +695,7 @@ generators _must_ be enabled to use the dynamic profiles.
feature spec.
- We'll also want to make sure that when we're serializing default/dynamic
profiles, we take into account the state from the global defaults, and we
don't duplicate that inormation into the entries for those types of profiles
don't duplicate that information into the entries for those types of profiles
in the user profiles.
* **Re-ordering profiles** - Under "Solution Design", we provide an algorithm
for decoding the settings. One of the steps mentioned is parsing the user

2
doc/specs/#976 - VT52 escape sequences.md
View File

@@ -84,7 +84,7 @@ Key | Sequence
With <kbd>Num Lock</kbd> disabled, most of the keys on the numeric keypad function the same as cursor keys or editing keys, but with the addition of a center <kbd>5</kbd> key. As a described above, the cursor keys generate a simple ESC prefix instead of CSI or SS3, while the editing keys remain unchanged (with the exception of modifiers).
In V52 mode, most modifiers are ignored, except for <kbd>Shift</kbd>, which is the equivalent of enabling <kbd>Num Lock</kbd> (i.e. the keys just generate their corresponding digit characters or `.`). With <kbd>Num Lock</kbd> enabled, it's the other way arround - the digits are generated by default, while <kbd>Shift</kbd> enables the cursor/editing functionality.
In V52 mode, most modifiers are ignored, except for <kbd>Shift</kbd>, which is the equivalent of enabling <kbd>Num Lock</kbd> (i.e. the keys just generate their corresponding digit characters or `.`). With <kbd>Num Lock</kbd> enabled, it's the other way around - the digits are generated by default, while <kbd>Shift</kbd> enables the cursor/editing functionality.
Key | Alias | ANSI mode | VT52 mode
-------------|-------|-----------|-----------