mirror of
https://github.com/microsoft/terminal.git
synced 2025-12-19 18:11:39 -05:00
ci: upgrade to check-spelling v0.0.24 (#18261)
This upgrades to [check-spelling v0.0.24]. A number of GitHub APIs are being turned off shortly, so we need to upgrade or various uncertain outcomes will occur. There are some minor bugs that I'm aware of and which I've fixed since this release (including a couple I discovered while preparing this PR). There's a new accessibility forbidden pattern: #### Should be `cannot` (or `can't`) See https://www.grammarly.com/blog/cannot-or-can-not/ > Don't use `can not` when you mean `cannot`. The only time you're likely to see `can not` written as separate words is when the word `can` happens to precede some other phrase that happens to start with `not`. > `Can't` is a contraction of `cannot`, and it's best suited for informal writing. > In formal writing and where contractions are frowned upon, use `cannot`. > It is possible to write `can not`, but you generally find it only as part of some other construction, such as `not only . . . but also.` - if you encounter such a case, add a pattern for that case to patterns.txt. ``` \b[Cc]an not\b ``` [check-spelling v0.0.24]: https://github.com/check-spelling/check-spelling/releases/tag/v0.0.24 Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
This commit is contained in:
Josh Soref
@@ -109,7 +109,7 @@ We'll be using tags, primarily, to help us understand what needs attention, what
|
||||
- Will use Squash merge strategy
|
||||
- Will attempt to delete branch after merge, if possible
|
||||
- Will automatically remove the `AutoMerge` label if changes are pushed by someone *without* Write Access.
|
||||
- More information on bot-logic that can be controlled with comments is [here](https://github.com/OfficeDev/office-ui-fabric-react/wiki/Advanced-auto-merge)
|
||||
- See more [information on bot-logic that can be controlled with comments](https://github.com/OfficeDev/office-ui-fabric-react/wiki/Advanced-auto-merge)
|
||||
|
||||
#### Mark issues with an active PR
|
||||
- If there is an active PR for an issue, label that issue with the `In-PR` label
|
||||
|
||||
@@ -1917,7 +1917,7 @@
|
||||
},
|
||||
"useCommandline": {
|
||||
"default": false,
|
||||
"description": "When set to `true`, the current commandline the user has typed will pre-populate the filter of the Suggestions UI. This requires that the user has enabled shell integration in their shell's config. When set to false, the filter will start empty."
|
||||
"description": "When set to `true`, the current commandline the user has typed will prepopulate the filter of the Suggestions UI. This requires that the user has enabled shell integration in their shell's config. When set to false, the filter will start empty."
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -2869,7 +2869,7 @@
|
||||
"description": "When true, this profile should always open in an elevated context. If the window isn't running as an Administrator, then a new elevated window will be created."
|
||||
},
|
||||
"environment": {
|
||||
"description": "Key-value pairs representing environment variables to set. Environment variable names are not case sensitive. You can reference existing environment variable names by enclosing them in literal percent characters (e.g. %PATH%).",
|
||||
"description": "Key-value pairs representing environment variables to set. Environment variable names are not case-sensitive. You can reference existing environment variable names by enclosing them in literal percent characters (e.g. %PATH%).",
|
||||
"type": "object",
|
||||
"additionalProperties": {
|
||||
"type": "string"
|
||||
|
||||
@@ -25,12 +25,12 @@ Two new properties should be added in the json settings file:
|
||||
|
||||
1. All spaces will be ignored.
|
||||
|
||||
2. Both X value and Y values are optional. If anyone of them is missing, or the value is invalid, system default value will be used. Examples:
|
||||
2. Both X value and Y values are optional. If any one of them is missing, or the value is invalid, system default value will be used. Examples:
|
||||
|
||||
", 1000" equals to (default, 1000)
|
||||
"1000, " equals to (1000, default)
|
||||
"," equals to (default, default)
|
||||
"abc, 1000" equals to (default, 1000)
|
||||
", 1000" equals (default, 1000)
|
||||
"1000, " equals (1000, default)
|
||||
"," equals (default, default)
|
||||
"abc, 1000" equals (default, 1000)
|
||||
|
||||
**launchMode**: string. Determine the launch mode. There are two modes for now
|
||||
|
||||
@@ -41,10 +41,10 @@ The steps of this process:
|
||||
|
||||
1. Set the top-left origin, width and height to CW_USEDEFAULT.
|
||||
2. Get the dpi of the nearest monitor; Load settings.
|
||||
3. From settings, find the user-defined initial position and launch mode.
|
||||
3. From settings, find the user-defined initial position and launch mode.
|
||||
4. If the user sets custom initial position, calculate the new position considering the current dpi and monitor. If not, use system default value.
|
||||
5. If the user set launch mode as "maximize", calculate the new height and width. If the user choose "default", use system default size.
|
||||
6. SetWindowPos with the new position and dimension of the window.
|
||||
6. SetWindowPos with the new position and dimension of the window.
|
||||
|
||||
Step 2 to 6 should be done in `AppHost::_HandleCreateWindow`, which is consistent to the current code.
|
||||
|
||||
@@ -52,11 +52,11 @@ In step 4, we may need to consider the dpi of the current monitor and multi-moni
|
||||
|
||||
Edge cases:
|
||||
|
||||
1. Multiple monitors. The user should be able to set the initial position to any monitors attached. For the monitors on the left side of the major monitor, the initial position values are negative.
|
||||
1. Multiple monitors. The user should be able to set the initial position to any monitors attached. For the monitors on the left side of the major monitor, the initial position values are negative.
|
||||
2. If the initial position is larger than the screen resolution and the window top left corner is off-screen, we should let user be able to see and drag the window back on screen. One solution is to set the initial position to the top left corner of the nearest monitor if the top left is off-screen.
|
||||
3. If the user wants to launch maximized and provides an initial position, we should launch the maximized window on the top left corner of the monitor where the position is located.
|
||||
4. Launch the Terminal on a monitor with custom dpi. Changing the dpi of the monitor will not affect the initial position of the top left corner. So we do not need to handle this case.
|
||||
5. Launch the Terminal on a monitor with custom resolution. Changing the resolution will change the available point for the initial position. (2) already covers this case.
|
||||
4. Launch the Terminal on a monitor with custom dpi. Changing the dpi of the monitor will not affect the initial position of the top left corner. So we do not need to handle this case.
|
||||
5. Launch the Terminal on a monitor with custom resolution. Changing the resolution will change the available point for the initial position. (2) already covers this case.
|
||||
|
||||
## UI/UX Design
|
||||
|
||||
@@ -69,14 +69,14 @@ The rest of the UI will be the same of the current Terminal experience, except t
|
||||
|
||||
### Accessibility
|
||||
|
||||
Users can only set the initial position and launch mode in the Json file with keyboard. Thus, this will not affect accessibility.
|
||||
Users can only set the initial position and launch mode in the Json file with keyboard. Thus, this will not affect accessibility.
|
||||
|
||||
### Reliability
|
||||
We need to make sure that whatever the initial position is set, the user can access the Terminal window. This is guaranteed because if the top left corner position of the Terminal Window is out of screen, we put it on the top left corner of the screen.
|
||||
We need to make sure that whatever the initial position is set, the user can access the Terminal window. This is guaranteed because if the top left corner position of the Terminal Window is out of screen, we put it on the top left corner of the screen.
|
||||
|
||||
### Performance, Power, and Efficiency
|
||||
|
||||
More data reading and calculation will be included in Terminal Launch process, which may inversely influence the launch time. However, the impact is trivial.
|
||||
More data reading and calculation will be included in Terminal Launch process, which may inversely influence the launch time. However, the impact is trivial.
|
||||
|
||||
## Potential Issues
|
||||
|
||||
@@ -88,9 +88,9 @@ For now, this feature only allows the user to set initial position and choose wh
|
||||
|
||||
1. Save the position of the Terminal on exit, and restore the position on the next launch. This could be a true/false feature that users could choose to set.
|
||||
|
||||
2. We may need to consider multiple Terminal windows scenario. If the user opens multiple Terminal windows, then we need to consider how to save and restore the position.
|
||||
2. We may need to consider multiple Terminal windows scenario. If the user opens multiple Terminal windows, then we need to consider how to save and restore the position.
|
||||
|
||||
3. We may also consider more launch modes. Like full screen mode and minimized mode.
|
||||
3. We may also consider more launch modes. Like full screen mode and minimized mode.
|
||||
|
||||
GitHub issue for future follow-ups: https://github.com/microsoft/terminal/issues/766
|
||||
|
||||
|
||||
@@ -447,7 +447,7 @@ Another reason we shouldn't support keys being able to be lazy-bound to local
|
||||
snippets: It's entirely too easy for `malicious.exe` to create a file in
|
||||
`%HomePath%` that creates a snippet for `\u003pwn-your-machine.exe\r` (or
|
||||
similar). Any app can read your settings file, and it is again too easy for that
|
||||
malicious app to set it's own action `id` to the same as some other well-meaning
|
||||
malicious app to set its own action `id` to the same as some other well-meaning
|
||||
local snippet's ID which you DO have bound to a key.
|
||||
|
||||
When we first load the snippets from the `.wt.json` file, we'll want to also ask
|
||||
@@ -563,9 +563,9 @@ their own workflows.
|
||||
* We'd have inputs for the commandline, name, description.
|
||||
* Obviously, it'd be easy to have a "Add new" button (to open that dialog) on
|
||||
the snippets pane.
|
||||
* We could have `wt save` open that dialog pre-populated, rather than just
|
||||
* We could have `wt save` open that dialog prepopulated, rather than just
|
||||
saving the command directly.
|
||||
* We could even also find a way to pre-populate that dialog with the recent
|
||||
* We could even also find a way to prepopulate that dialog with the recent
|
||||
commands (from shell integration)!
|
||||
* As a potential v2.0 of the snippets file schema, we may look to the
|
||||
`.vscode/tasks.json` schema for inspiration. That file supports much more
|
||||
|
||||
@@ -240,7 +240,7 @@ Not listed above is [shell-driven autocompletion]. These aren't something that
|
||||
the Terminal can invoke all on its own - these are something the shell would
|
||||
need to invoke themselves.
|
||||
|
||||
#### Pre-populate the current commandline context
|
||||
#### Prepopulate the current commandline context
|
||||
|
||||
Consider the following scenario. A user has typed `git c` in their shell, and
|
||||
has [shell integration] enabled for their shell. They want to open the
|
||||
@@ -248,7 +248,7 @@ Suggestions UI filtered to their recent history, but starting with what they've
|
||||
already typed. To support this scenario, we'll add an additional property:
|
||||
|
||||
* `"useCommandline"`: `bool` (**default**: `true`)
|
||||
* `true`: the current commandline the user has typed will pre-populate the
|
||||
* `true`: the current commandline the user has typed will prepopulate the
|
||||
filter of the Suggestions UI. This requires that the user has enabled shell
|
||||
integration in their shell's config.
|
||||
* `false`: the filter will start empty, regardless of what the user has typed.
|
||||
@@ -388,7 +388,7 @@ spec's review.
|
||||
* [ ] Enable the `SuggestionsControl` to open with or without a search box
|
||||
* [ ] Plumb support for shell-driven completions through the core up to the app
|
||||
* [ ] Expose the _current_ commandline from the `TermControl`
|
||||
* [ ] Add a `useCommandline` property to `suggestions`, to pre-populate the search with the current commandline.
|
||||
* [ ] Add a `useCommandline` property to `suggestions`, to prepopulate the search with the current commandline.
|
||||
* [ ] Persist recent commands / directories accordingly
|
||||
|
||||
### 🏃♂️ Run
|
||||
@@ -436,7 +436,7 @@ Here's a sample json schema for the settings discussed here.
|
||||
},
|
||||
"useCommandline": {
|
||||
"default": false,
|
||||
"description": "When set to `true`, the current commandline the user has typed will pre-populate the filter of the Suggestions UI. This requires that the user has enabled shell integration in their shell's config. When set to false, the filter will start empty."
|
||||
"description": "When set to `true`, the current commandline the user has typed will prepopulate the filter of the Suggestions UI. This requires that the user has enabled shell integration in their shell's config. When set to false, the filter will start empty."
|
||||
},
|
||||
"nesting": {
|
||||
"default": true,
|
||||
@@ -591,7 +591,7 @@ We'll probably want a way for recent commands to be saved across sessions. That
|
||||
* If they're saved per-profile, maybe a profile can opt-in to loading all the commands?
|
||||
* How does defterm play with this? Do we "layer" by concatenating per-profile commands with `profiles.defaults` ones?
|
||||
* A button in the Settings UI for clearing these commands
|
||||
* Should fragments be able to pre-populate "recent commands"?
|
||||
* Should fragments be able to prepopulate "recent commands"?
|
||||
* I'm just gonna say _no_. That would be a better idea for Tasks (aka just a `sendInput` Action that we load from the fragment normally as a Task), or a specific suggestion source for the fragment extension.
|
||||
|
||||
#### Inline mode
|
||||
|
||||
@@ -698,7 +698,7 @@ This would define three commands, each with a number of nested commands undernea
|
||||
* The second command:
|
||||
- It uses the string literal `"Connect to ssh..."` as it's name
|
||||
- It contains two nested commands:
|
||||
- Each nested command has it's own literal name
|
||||
- Each nested command has its own literal name
|
||||
- Activating these commands would cause us to open a new tab with the
|
||||
provided `commandline` instead of the default profile's `commandline`
|
||||
* The third command:
|
||||
|
||||
@@ -10,7 +10,7 @@ issue id: 2046
|
||||
## Abstract
|
||||
|
||||
This document is intended to serve as an addition to the [Command Palette Spec].
|
||||
While that spec is complete in it's own right, subsequent discussion revealed
|
||||
While that spec is complete in its own right, subsequent discussion revealed
|
||||
additional ways to improve the functionality and usability of the command
|
||||
palette. This document builds largely on the topics already introduced in the
|
||||
original spec, so readers should first familiarize themselves with that
|
||||
|
||||
@@ -253,7 +253,7 @@ After much discussion as a team, we decided that **Proposal D** would be the
|
||||
best option. We felt that there wasn't a need to add any extra configuration to
|
||||
invoke the "pane switcher" as anything different than the "tab switcher". The
|
||||
"pane switcher" should really just exist as a part of the functionality of the
|
||||
advanced tab switcher, not as it's own thing.
|
||||
advanced tab switcher, not as its own thing.
|
||||
|
||||
Additionally, we concurred that the new "direction" value should be `prev`, not
|
||||
`last`, for consistency's sake.
|
||||
|
||||
@@ -225,7 +225,7 @@ The window process can listen for that event to indicate that the swapchain
|
||||
changed. The window will then query for the content process's PID and create a
|
||||
handle to the content process. The window will query the current value of the
|
||||
content process's `HANDLE` to the swapchain. The window will then duplicate that
|
||||
`HANDLE` into it's own process space. Now that the window has a handle to the
|
||||
`HANDLE` into its own process space. Now that the window has a handle to the
|
||||
swapchain, it can use [`ISwapChainPanelNative2::SetSwapChainHandle`] to set the
|
||||
SwapChainPanel to use the same swapchain.
|
||||
|
||||
@@ -449,7 +449,7 @@ schemes for the commandline parameters. The following is given as an example of
|
||||
how these arguments _might_ be authored and implemented to satisfy some of these
|
||||
scenarios.
|
||||
|
||||
Since each window process will have it's own unique ID assigned to it by the
|
||||
Since each window process will have its own unique ID assigned to it by the
|
||||
monarch, then running a command in a given window with ID `N` should be as easy
|
||||
as something like:
|
||||
|
||||
@@ -627,7 +627,7 @@ Then we have two paths forward:
|
||||
It should create a new content process to handle this connection.
|
||||
- the content process will need a way of being invoked by passing it handles
|
||||
to the new client. This way, the content process can dupe these handles into
|
||||
it's own process space, to be able to create the `ITerminalConnection` in
|
||||
its own process space, to be able to create the `ITerminalConnection` in
|
||||
its own process space.
|
||||
|
||||
3. If this new window process is the monarch, then great! There are no other
|
||||
@@ -808,7 +808,7 @@ The Settings UI is something we intend on shipping in the Terminal as a part of
|
||||
also plan on hopefully making the Settings UI appear as its own tab within the
|
||||
Terminal. This would be the first example of having non-terminal content
|
||||
directly in the application. How would we support tearing out the Settings UI
|
||||
tab into it's own window?
|
||||
tab into its own window?
|
||||
|
||||
Options available here include:
|
||||
|
||||
@@ -967,7 +967,7 @@ of each other.
|
||||
- Summon the nearest window
|
||||
- make the window "drop down" from the top
|
||||
- Summon the MRU window
|
||||
- It would need to track a the MRU for windows, so pressing the shortcut when
|
||||
- It would need to track the MRU for windows, so pressing the shortcut when
|
||||
no window is active summons the MRU one.
|
||||
|
||||
<hr>
|
||||
|
||||
@@ -46,7 +46,7 @@ application, and each tab has a set of panes that are visible within the context
|
||||
of that tab.
|
||||
|
||||
Panes are implemented as a binary tree of panes. A Pane can either be a leaf
|
||||
pane, with it's own terminal control that it displays, or it could be a parent
|
||||
pane, with its own terminal control that it displays, or it could be a parent
|
||||
pane, where it has two children, each with their own terminal control.
|
||||
|
||||
When a pane is a parent, its two children are either split vertically or
|
||||
@@ -211,7 +211,7 @@ no means a comprehensive list.
|
||||
|
||||
### Why not top-level panes, and nested tabs?
|
||||
|
||||
If each pane were to have it's own set of tabs, then each pane would need to
|
||||
If each pane were to have its own set of tabs, then each pane would need to
|
||||
reserve screen real estate for a row of tabs. As a user continued to split the
|
||||
window, more and more of the screen would be dedicated to just displaying a row
|
||||
of tabs, which isn't really the important part of the application, the terminal
|
||||
@@ -223,10 +223,10 @@ user would need to somehow close the other panes, to be able to make the split
|
||||
the size of the dull window.
|
||||
|
||||
One con of this design is that if a control is hosted in a pane, the current
|
||||
design makes it hard to move out of a pane into it's own tab, or into another
|
||||
design makes it hard to move out of a pane into its own tab, or into another
|
||||
pane. This could be solved a number of ways. There could be keyboard shortcuts
|
||||
for swapping the positions of tabs, or a shortcut for both "zooming" a tab
|
||||
(temporarily making it the full size) or even popping a pane out to it's own
|
||||
(temporarily making it the full size) or even popping a pane out to its own
|
||||
tab. Additionally, a right-click menu option could be added to do the
|
||||
aforementioned 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
|
||||
|
||||
@@ -9,81 +9,81 @@ issue id: #605
|
||||
|
||||
## Abstract
|
||||
|
||||
This spec is for feature request #605 "Search". It goes over the details of a new feature that allows users to search text in Terminal, within one tab or from all tabs. Expected behavior and design of this feature is included. Besides, future possible follow-up works are also addressed.
|
||||
This spec is for feature request #605 "Search". It goes over the details of a new feature that allows users to search text in Terminal, within one tab or from all tabs. Expected behavior and design of this feature is included. Besides, future possible follow-up works are also addressed.
|
||||
|
||||
## Inspiration
|
||||
|
||||
One of the superior features of iTerm2 is it's content search. The search comes in two variants: search from active tab and search from all tabs. In almost any editor, there is an roughly equivalent string search. We also want to realize search experience in Terminal. There will be two variants, search within one tab or from multiple tabs. We will start with one-tab search implementation.
|
||||
One of the superior features of iTerm2 is it's content search. The search comes in two variants: search from active tab and search from all tabs. In almost any editor, there is an roughly equivalent string search. We also want to realize search experience in Terminal. There will be two variants, search within one tab or from multiple tabs. We will start with one-tab search implementation.
|
||||
|
||||
## Solution Design
|
||||
|
||||
Our ultimate goal is to provide both search within one tab and search from all tabs experiences. But we can start with one-tab search. The search experience should have following features:
|
||||
|
||||
1. The search is triggered by KeyBindings. A new setting property named "find" will be enabled in the Json file. The user can set their own key bindings for search. The default is <kbd>ctrl+shift+f</kbd>.
|
||||
1. The search is triggered by KeyBindings. A new setting property named "find" will be enabled in the Json file. The user can set their own key bindings for search. The default is <kbd>ctrl+shift+f</kbd>.
|
||||
2. The user search in a XAML TextBox, which is contained in a custom `SearchBoxControl`. The default position of the search box is the top right corner.
|
||||
3. We can have multiple search methods. The simplest one is exact text match. Other match methods include case-sensitive exact match and regex match. In the first phase, we will focus on case sensitive/insensitive text exact match.
|
||||
3. We can have multiple search methods. The simplest one is exact text match. Other match methods include case-sensitive exact match and regex match. In the first phase, we will focus on case-sensitive/insensitive text exact match.
|
||||
4. If currently there is no active selection, the search starts from the last line of the mutableViewport. If there is an active selection, we start from the previous or the next text of the selected text. We automatically go around if we reach the start point of the search.
|
||||
5. The user should be able to fully interact with the terminal when the search box is on screen.
|
||||
5. The user should be able to fully interact with the terminal when the search box is on screen.
|
||||
6. For accessibility concerns, the user should be able to navigate all the interactive elements on the search box using keyboard tab if the search box is focused. Searchbox could be created and closed with keyboard bindings. Close is usually bound to Esc.
|
||||
|
||||
Conhost already has a module for search. It implements case sensitive or insensitive exact text match search, and it provides methods to select the found word. However, we want to make search as a shared component between Terminal and Console host. Now search module is part of Conhost, and its dependencies include BufferOut and some other types in ConHost such as SCREEN_INFORMATION. In order to make Search a shared component, we need to remove its dependency on ConHost types. BufferOut is already a shared component, but we need to make sure there is no other Conhost dependency.
|
||||
Conhost already has a module for search. It implements case-sensitive or insensitive exact text match search, and it provides methods to select the found word. However, we want to make search as a shared component between Terminal and Console host. Now search module is part of Conhost, and its dependencies include BufferOut and some other types in ConHost such as SCREEN_INFORMATION. In order to make Search a shared component, we need to remove its dependency on ConHost types. BufferOut is already a shared component, but we need to make sure there is no other Conhost dependency.
|
||||
|
||||
We will create a `SearchBoxControl` Xaml `UserControl` element. When a search process begins, a `SearchBoxControl` object will be created and attached to `TermControl` root grid. In other words, one SearchBox is added for each `TermControl`. The reasons for this design is:
|
||||
|
||||
1. Each `TermControl` object is a Terminal Window and has a individual text buffer. In phase 1 we are going to search within the current terminal text buffer.
|
||||
2. If we put the search box under TerminalApp, then the search can only happen on the current focused Terminal.
|
||||
3. If the community does not like the current design, we can lift SearchBox to a higher level.
|
||||
1. Each `TermControl` object is a Terminal Window and has a individual text buffer. In phase 1 we are going to search within the current terminal text buffer.
|
||||
2. If we put the search box under TerminalApp, then the search can only happen on the current focused Terminal.
|
||||
3. If the community does not like the current design, we can lift SearchBox to a higher level.
|
||||
|
||||
### Search process implementation
|
||||
1. Once the user press <kbd>ctrl+shift+f</kbd> (or user's custom key binding), a new `SearchBoxControl` object will be created and attached as a child of `TermControl`. Focus will move to the TextBox within the `SearchBoxControl`.
|
||||
1. Once the user press <kbd>ctrl+shift+f</kbd> (or user's custom key binding), a new `SearchBoxControl` object will be created and attached as a child of `TermControl`. Focus will move to the TextBox within the `SearchBoxControl`.
|
||||
2. Search is performed on a XAML TextBox. Once the user presses Enter or click up/down arrow button, we start to search from the last line of the current viewport or the current selection, and try to find the exact text in the text buffer. The nearest searched one will be selected. Then the search start point will be set to the selected text. The next search will start before or after the previous searched text.
|
||||
3. We re-use the Search module in conhost. It performs the search in a brute-force approach. Starting from every position in the text buffer, the search algorithm compares the span of the searched string with buffer characters, and if the current buffer text matches the whole string, it will return store the position of the text in the buffer and return. The stored position information will be used for selection.
|
||||
3. The user can choose to search up or down. Search module realizes this, we just need to set a boolean flag. Default is search up.
|
||||
4. The user can choose to do case sensitive or insensitive match. This also realized by Search module by setting a boolean flag. Default is search case-insensitively.
|
||||
5. Tab navigation is realized by XAML. We just need to set TabNavigation="Cycle" in `SearchBoxControl`.
|
||||
6. If the user clicks on the "X" button or press <kbd>Esc</kbd>, the search box will disappear and the object will be destructed and detached from the `TermControl` XAML tree. In phase one we do not store any state.
|
||||
7. We need to guarantee full interaction with the terminal when the search box is open. To achieve this, search box and terminal input should be separated. If the current keyboard focus is on the search box, then keydown events will be handled on "search box level".
|
||||
3. We re-use the Search module in conhost. It performs the search in a brute-force approach. Starting from every position in the text buffer, the search algorithm compares the span of the searched string with buffer characters, and if the current buffer text matches the whole string, it will return store the position of the text in the buffer and return. The stored position information will be used for selection.
|
||||
3. The user can choose to search up or down. Search module realizes this, we just need to set a boolean flag. Default is search up.
|
||||
4. The user can choose to do case-sensitive or insensitive match. This also realized by Search module by setting a boolean flag. Default is search case-insensitively.
|
||||
5. Tab navigation is realized by XAML. We just need to set TabNavigation="Cycle" in `SearchBoxControl`.
|
||||
6. If the user clicks on the "X" button or press <kbd>Esc</kbd>, the search box will disappear and the object will be destructed and detached from the `TermControl` XAML tree. In phase one we do not store any state.
|
||||
7. We need to guarantee full interaction with the terminal when the search box is open. To achieve this, search box and terminal input should be separated. If the current keyboard focus is on the search box, then keydown events will be handled on "search box level".
|
||||
|
||||
## UI/UX Design
|
||||
|
||||
|
||||
|
||||
Above is the `SearchBoxControl` in dark theme and light theme.
|
||||
- The two buttons with up/down arrows controls the search direction, Each button will be styled to indicate which search direction is currently selected.
|
||||
- The button with a "Aa" icon, if pressed, means that we are searching case-sensitivity.
|
||||
- The current style puts all elements - the `X` button, the text box and the search pattern control buttons on one single line. This ensures that the `SearchBoxControl` won't be too high and block terminal text. This is similar with VSCode. Another possible layout style is to put elements in multiple layers. This will occupy more lines, but the search dialog will narrower. Considering that there is not many elements, we do not need multiple layers.
|
||||
- The two buttons with up/down arrows controls the search direction, Each button will be styled to indicate which search direction is currently selected.
|
||||
- The button with a "Aa" icon, if pressed, means that we are searching case-sensitivity.
|
||||
- The current style puts all elements - the `X` button, the text box and the search pattern control buttons on one single line. This ensures that the `SearchBoxControl` won't be too high and block terminal text. This is similar with VSCode. Another possible layout style is to put elements in multiple layers. This will occupy more lines, but the search dialog will narrower. Considering that there is not many elements, we do not need multiple layers.
|
||||
|
||||
|
||||
|
||||
The search box defaults to be on the top right corner of the Terminal window. If the current tab is split into panes, each pane will have a individual searchbox.
|
||||
The search box defaults to be on the top right corner of the Terminal window. If the current tab is split into panes, each pane will have a individual searchbox.
|
||||
|
||||
#### Search process
|
||||
1. The user presses <kbd>ctrl+shift+f</kbd> (or user's custom key binding) to open the search box. Focus will move to the TextBox.
|
||||
2. Search is performed on a XAML TextBox. Once the user presses Enter or click up/down arrow button, the search starts and searched text will be selected. Next search will be performed beginning from the current selection and go towards up/down.
|
||||
3. The user can choose to search up or down by selecting up arrow or down arrow buttons. The chosen button will be styled to indicate it is selected. If the user does not click the arrows buttons, the default direction is up.
|
||||
4. The user can choose to do case sensitive or insensitive match by checking a check box. The default is case insensitive.
|
||||
5. If the search box is focused, the user can navigate all the elements on the search box using tab. When selected, press Enter equals to click.
|
||||
1. The user presses <kbd>ctrl+shift+f</kbd> (or user's custom key binding) to open the search box. Focus will move to the TextBox.
|
||||
2. Search is performed on a XAML TextBox. Once the user presses Enter or click up/down arrow button, the search starts and searched text will be selected. Next search will be performed beginning from the current selection and go towards up/down.
|
||||
3. The user can choose to search up or down by selecting up arrow or down arrow buttons. The chosen button will be styled to indicate it is selected. If the user does not click the arrows buttons, the default direction is up.
|
||||
4. The user can choose to do case-sensitive or insensitive match by checking a check box. The default is case-insensitive.
|
||||
5. If the search box is focused, the user can navigate all the elements on the search box using tab. When selected, pressing Enter is equivalent to clicking.
|
||||
6. If the user click the "X" button or press <kbd>Esc</kbd>, the search stopped and the search box disappears and focus will move back to Terminal.
|
||||
7. Once the search box is closed (exiting search mode), the selection will still be there. This coincides with the current VS Code and cmd experience. To get rid of the selection, the user can just click other area of the window.
|
||||
8. If the user clicks on the terminal when the search box is open, it will draw focus back to the terminal from the search box. The search box will still stay open.
|
||||
9. The user can interact with the terminal when the search box is open, which means that the user can scroll the terminal content, or input text when the focus is on the terminal control.
|
||||
10. If the user switches tabs while the search box is open, the focus will be moved back to the terminal.
|
||||
8. If the user clicks on the terminal when the search box is open, it will draw focus back to the terminal from the search box. The search box will still stay open.
|
||||
9. The user can interact with the terminal when the search box is open, which means that the user can scroll the terminal content, or input text when the focus is on the terminal control.
|
||||
10. If the user switches tabs while the search box is open, the focus will be moved back to the terminal.
|
||||
|
||||
## Capabilities
|
||||
|
||||
1. The user can search exact matched text in the text buffer of the Terminal Screen.
|
||||
2. The user can choose to search case sensitively and insensitively.
|
||||
3. The user can search up or down.
|
||||
4. Found text will be selected.
|
||||
5. The search will start from the active selected text (inclusive) if there is one, or the end of the written text.
|
||||
1. The user can search exact matched text in the text buffer of the Terminal Screen.
|
||||
2. The user can choose to search case-sensitively and insensitively.
|
||||
3. The user can search up or down.
|
||||
4. Found text will be selected.
|
||||
5. The search will start from the active selected text (inclusive) if there is one, or the end of the written text.
|
||||
6. The search will automatically go around when it reaches the starting point.
|
||||
7. The user can use Tab to navigate all the elements in the search box.
|
||||
8. The user can search in the opposite direction with <kbd>Shift + Enter</kbd>
|
||||
7. The user can use Tab to navigate all the elements in the search box.
|
||||
8. The user can search in the opposite direction with <kbd>Shift + Enter</kbd>
|
||||
|
||||
### Accessibility
|
||||
|
||||
The user should be able to use search by keyboard only.
|
||||
Once the searchbox is focused, the user can navigate between elements in the search box using Tab. And "click" using Enter.
|
||||
Once the searchbox is focused, the user can navigate between elements in the search box using Tab. And "click" using Enter.
|
||||
|
||||
### Security
|
||||
|
||||
@@ -91,8 +91,8 @@ This feature should not introduce any new security issues.
|
||||
|
||||
### Reliability
|
||||
|
||||
1. The key input of Terminal command line and the search box should be separated. Search box should not block interaction with the command line when it is open.
|
||||
2. The search box should not block too much text. The search box only occupies one line, so it won't have big impact on the readability of the terminal output.
|
||||
1. The key input of Terminal command line and the search box should be separated. Search box should not block interaction with the command line when it is open.
|
||||
2. The search box should not block too much text. The search box only occupies one line, so it won't have big impact on the readability of the terminal output.
|
||||
|
||||
### Compatibility
|
||||
|
||||
@@ -100,23 +100,23 @@ This feature won't break existing features of Terminal.
|
||||
|
||||
### Performance, Power, and Efficiency
|
||||
|
||||
This feature only launches in need. It does not impact the performance of Terminal.
|
||||
This feature only launches in need. It does not impact the performance of Terminal.
|
||||
|
||||
## Potential Issues
|
||||
|
||||
|
||||
1. If the terminal window is not wide enough for the search box to be visible, the buttons on the right of the `TextBox` will become invisible, but the `TextBox` is still visible and the window could not be narrower than the `TextBox`. This is similar to the behavior of other editors. Please see the image below:
|
||||
|
||||
2. If the terminal window is not high enough for the search box to be visible, the whole terminal screen, including the `SearchBoxControl` can disappear. This is similar to the behavior of other editors.
|
||||
|
||||
## Future considerations
|
||||
|
||||
In version 1, we want realize a case sensitive/insensitive exact text match. But we may consider the following features in version 2:
|
||||
In version 1, we want realize a case-sensitive/insensitive exact text match. But we may consider the following features in version 2:
|
||||
|
||||
1. Add "Find" button in dropdown menu to trigger search. This enables the search feature to be operated with mouse only. However, this is not required by Accessibility so we do not cover this in phase one.
|
||||
2. Search from all tabs. For Version 1 we just want to realize search within one tab. However, the community also requests search from all tabs. This may require a big change to the search algorithm, but it is not seen as a popular use scenario, so we put it future phase. To implement multi-tab search, we can let TerminalPage or App own a `SearchBoxControl` object, and provide the text buffer of the current focused terminal. We need to change the search algorithm.
|
||||
1. Add "Find" button in dropdown menu to trigger search. This enables the search feature to be operated with mouse only. However, this is not required by Accessibility so we do not cover this in phase one.
|
||||
2. Search from all tabs. For Version 1 we just want to realize search within one tab. However, the community also requests search from all tabs. This may require a big change to the search algorithm, but it is not seen as a popular use scenario, so we put it future phase. To implement multi-tab search, we can let TerminalPage or App own a `SearchBoxControl` object, and provide the text buffer of the current focused terminal. We need to change the search algorithm.
|
||||
3. Regular expression match. This is a useful search pattern and is implemented in some editors. However, this use scenario is not used as much as exact text search, thus, we put it in future phase.
|
||||
4. Search history. Sometimes users would do the same search for several times, thus, storing the search history is useful. This is not realized by VSCode so it would be a good highlighting point in the future.
|
||||
5. High-light while you type. Emphasizing all the other matches in the buffer with an outline or selection with another color. This provides a clearer view of searched text. But we need to change the search and selection algorithm, so we put it in the future phase.
|
||||
4. Search history. Sometimes users would do the same search for several times, thus, storing the search history is useful. This is not realized by VSCode so it would be a good highlighting point in the future.
|
||||
5. High-light while you type. Emphasizing all the other matches in the buffer with an outline or selection with another color. This provides a clearer view of searched text. But we need to change the search and selection algorithm, so we put it in the future phase.
|
||||
6. Add size handle. Some text editors let the user resize the search box, and there is a size handle on the left side of the search box. This helps user when they search for long text. If the community desires it we may add a similar feature.
|
||||
|
||||
This open issue tracks the phase features of Search: https://github.com/microsoft/terminal/issues/3920
|
||||
|
||||
@@ -346,7 +346,7 @@ asked for these features, then it's inevitable that our users will too 😉
|
||||
panes, not just key strokes. But which actions would those be? Moving the
|
||||
selection anchors? Copy doesn't really make sense. Paste _does_ though.
|
||||
Maybe the open find dialog / next&prev search match actions?
|
||||
- This probably would require it's own spec.
|
||||
- This probably would require its own spec.
|
||||
* [iterm2#6007] - Different stripe color for different broadcast modes
|
||||
- Have one color to indicate when broadcasting in `global` scope, another in
|
||||
`tab` scope, a third in `pane` scope.
|
||||
|
||||
@@ -11,7 +11,7 @@ issue id: #10509
|
||||
## Abstract
|
||||
|
||||
This document serves as a companion doc to the [Theming Spec], rather than a
|
||||
spec on it's own. The context of broader application-level theming support is
|
||||
spec on its own. The context of broader application-level theming support is
|
||||
necessary to understand the big picture of the designs in this discussion.
|
||||
|
||||
|
||||
|
||||
@@ -264,12 +264,12 @@ whatever client application (`cmd`, `powershell`, `bash`, `vim`) that is
|
||||
connected to it. WT doesn't know when the user is typing in commands to the
|
||||
shell, or if the user is just typing in text in `emacs` or something. There's no
|
||||
way for the terminal to know that. It's _typically_ the client application's
|
||||
responsibility to save it's own command history. `bash` and `powershell` both do
|
||||
responsibility to save its own command history. `bash` and `powershell` both do
|
||||
a pretty good job of saving this to another file to restore across sessions,
|
||||
while `cmd.exe` doesn't.
|
||||
|
||||
Windows is a messy world and this model gets a little tricky here. `cmd.exe`
|
||||
isn't actually managing it's own command history _at all_. `conhost` is doing
|
||||
isn't actually managing its own command history _at all_. `conhost` is doing
|
||||
that work on behalf of the client applications. Some long time ago someone
|
||||
thought it would be a good idea to have the `readline` functionality baked
|
||||
directly into the console host. Whether that was a good idea or not remains to
|
||||
|
||||
@@ -70,7 +70,7 @@ With more possible controls in a pane than just a terminal, it's possible that
|
||||
crashes in those controls could impact the entire Terminal app's reliability.
|
||||
This would largely be out of our control, as we only author the TermControl.
|
||||
|
||||
We may want to consider hosting each pane in it's own process, similar to how
|
||||
We may want to consider hosting each pane in its own process, similar to how
|
||||
moder browsers will host each tab in its own process, to help isolate tabs. This
|
||||
is a bigger discussion than the feature at hand, however.
|
||||
|
||||
|
||||
@@ -33,7 +33,8 @@ The jumplist has to be created/modified during the life-cycle of the application
|
||||
UWP provides an API to access to the jumplist through the [Windows.UI.StartScreen.JumpList class](https://docs.microsoft.com/en-us/uwp/api/windows.ui.startscreen.jumplist), however from previous attempts [1], the api does not work for the project architecture.
|
||||
Instead, we'll use the COM interface [ICustomDestinationList](https://docs.microsoft.com/en-us/windows/desktop/api/shobjidl_core/nn-shobjidl_core-icustomdestinationlist) [2] directly to create the jumplist. Since we are using Win32 apis, the work should be done in the `WindowsTerminal` project.
|
||||
|
||||
Using `ICustomDestinationList` is straightforward with a few additions discussed in this section [below](#Implementation-notes). Resources for using the jumplist can be found [here](https://msdn.microsoft.com/en-us/library/windows/desktop/gg281362.aspx) and [here](https://www.codeproject.com/Articles/36561/Windows-7-Goodies-in-C-Jump-Lists).
|
||||
Using `ICustomDestinationList` is straightforward with a few additions discussed in this section [below](#Implementation-notes). See [Adding Support for Windows 7 Jump Lists & Taskbar Tabs](https://msdn.microsoft.com/en-us/library/windows/desktop/gg281362.aspx) and [Windows 7 Goodies in C++: Jump Lists](https://www.codeproject.com/Articles/36561/Windows-7-Goodies-in-C-Jump-Lists).
|
||||
|
||||
|
||||
The basic overview:
|
||||
1. Get an instance of the `ICustomDestinationList` COM object
|
||||
|
||||
Reference in New Issue
Block a user