mirror of
https://github.com/nsnail/spectre.console.git
synced 2025-04-14 16:02:50 +08:00
Fix typos
This commit is contained in:
parent
b058c54f3c
commit
64f444114a
@ -8,7 +8,7 @@ Highlights:
|
||||
- And more...
|
||||
---
|
||||
|
||||
There is different built-in borders you can use for tables and panels.
|
||||
There are different built-in borders you can use for tables and panels.
|
||||
|
||||
## Table borders
|
||||
|
||||
|
@ -25,7 +25,7 @@ AnsiConsole.Status()
|
||||
To implement your own spinner, all you have to do is
|
||||
inherit from the `Spinner` base class.
|
||||
|
||||
In the example below, the spinner will alterate between
|
||||
In the example below, the spinner will alternate between
|
||||
the characters `A`, `B` and `C` every 100 ms.
|
||||
|
||||
```csharp
|
||||
|
@ -20,7 +20,7 @@ app.Configure(config =>
|
||||
|
||||
## Multiple Commands
|
||||
|
||||
In the previous example we have a single command that is configured. For complex command line applications, it is common for them to have multiple commands (or verbs) defined. Examples of applications like this are `git`, `dotnet` and `gh`. For example, git would have an `commit` command and along with other commits like `add` or `rebase`. Each with their own settings and validation. With `Spectre.Console.Cli` we use the `Configure` method to add these commands.
|
||||
In the previous example we have a single command that is configured. For complex command line applications, it is common for them to have multiple commands (or verbs) defined. Examples of applications like this are `git`, `dotnet` and `gh`. For example, git would have a `commit` command and along with other commits like `add` or `rebase`. Each with their own settings and validation. With `Spectre.Console.Cli` we use the `Configure` method to add these commands.
|
||||
|
||||
For example, to add three different commands to the application:
|
||||
|
||||
@ -34,7 +34,7 @@ app.Configure(config =>
|
||||
});
|
||||
```
|
||||
|
||||
This configuration would allow users to run `app.exe add`, `app.exe commit`, or `app.exe rebase` and have the settings routed the appropriate command.
|
||||
This configuration would allow users to run `app.exe add`, `app.exe commit`, or `app.exe rebase` and have the settings routed to the appropriate command.
|
||||
|
||||
For more complex command hierarchical configurations, they can also be composed via inheritance and branching. See [Composing Commands](./composing).
|
||||
|
||||
@ -76,7 +76,7 @@ return app.Run(args);
|
||||
|
||||
## Interception
|
||||
|
||||
`CommandApp` also provides a `SetInterceptor` configuration. An interceptor is ran before all commands are executed. This is typically used for configuring logging or other infrastructure concerns.
|
||||
`CommandApp` also provides a `SetInterceptor` configuration. An interceptor is run before all commands are executed. This is typically used for configuring logging or other infrastructure concerns.
|
||||
|
||||
All interceptors must implement `ICommandInterceptor`. Upon execution of a command, an instance of your interceptor will be called with the parsed settings. This provides an opportunity for configuring any infrastructure or modifying the settings.
|
||||
|
||||
|
@ -111,7 +111,7 @@ Now you might wonder, why do things like this? Well, for starters the different
|
||||
of the application are separated, while still having the option to share things like options,
|
||||
flags and arguments between them.
|
||||
|
||||
This make the resulting code very clean and easy to navigate, not to mention to unit test.
|
||||
This makes the resulting code very clean and easy to navigate, not to mention to unit test.
|
||||
And most importantly at all, the type system guides me to do the right thing. I can't configure
|
||||
commands in non-compatible ways, and if I want to add a new top-level `add-package` command
|
||||
(or move the command completely), it's just a single line to change. This makes it easy to
|
||||
|
@ -67,7 +67,7 @@ This command will have three parameters.
|
||||
|
||||
When `args` is passed into the `CommandApp`'s run method, `Spectre.Console.Cli` will parse those arguments and populate an instance of your settings. Upon success, it will then pass those settings into an instance of the specified command's `Execute` method.
|
||||
|
||||
With this in place, we can the following commands will all work
|
||||
With this in place, the following commands will all work
|
||||
|
||||
```text
|
||||
app.exe
|
||||
|
@ -117,7 +117,7 @@ Now you might wonder, why do things like this? Well, for starters the different
|
||||
of the application are separated, while still having the option to share things like options,
|
||||
flags and arguments between them.
|
||||
|
||||
This make the resulting code very clean and easy to navigate, not to mention to unit test.
|
||||
This makes the resulting code very clean and easy to navigate, not to mention to unit test.
|
||||
And most importantly at all, the type system guides me to do the right thing. I can't configure
|
||||
commands in non-compatible ways, and if I want to add a new top-level `add-package` command
|
||||
(or move the command completely), it's just a single line to change. This makes it easy to
|
||||
|
@ -1,6 +1,6 @@
|
||||
Title: Migrate from Spectre.Cli
|
||||
Order: 10
|
||||
Description: "Migrating from *Specte.Cli* to *Spectre.Console.Cli*"
|
||||
Description: "Migrating from *Spectre.Cli* to *Spectre.Console.Cli*"
|
||||
---
|
||||
|
||||
The functionality in `Spectre.Cli` has been moved into the `Spectre.Console`
|
||||
@ -26,7 +26,7 @@ Add the [Spectre.Console](https://www.nuget.org/packages/spectre.console) NuGet
|
||||
## 3. Change using statements
|
||||
|
||||
Change all using statements from `Spectre.Cli`
|
||||
to `Spectre.Console.CLi`.
|
||||
to `Spectre.Console.Cli`.
|
||||
|
||||
```diff
|
||||
- using Spectre.Cli;
|
||||
|
@ -22,7 +22,7 @@ This setting file tells `Spectre.Console.Cli` that our command has two parameter
|
||||
|
||||
## CommandArgument
|
||||
|
||||
Arguments have a position and a name. The name is not only used for generating help, but it's formatting is used to determine whether or not the argument is optional. The name must either be surrounded by square brackets (e.g. `[name]`) or angle brackets (e.g. `<name>`). Angle brackets denote required whereas square brackets denote optional. If neither are specified an exception will be thrown.
|
||||
Arguments have a position and a name. The name is not only used for generating help, but its formatting is used to determine whether or not the argument is optional. The name must either be surrounded by square brackets (e.g. `[name]`) or angle brackets (e.g. `<name>`). Angle brackets denote required whereas square brackets denote optional. If neither are specified an exception will be thrown.
|
||||
|
||||
The position is used for scenarios where there could be more than one argument.
|
||||
|
||||
|
@ -81,7 +81,7 @@ For a list of emoji, see the [Emojis](xref:emojis) appendix section.
|
||||
|
||||
## Colors
|
||||
|
||||
In the examples above, all colors was referenced by their name,
|
||||
In the examples above, all colors were referenced by their name,
|
||||
but you can also use the hex or rgb representation for colors in markdown.
|
||||
|
||||
```csharp
|
||||
|
@ -36,7 +36,7 @@ AnsiConsole.Render(image);
|
||||
## Manipulating images
|
||||
|
||||
You can take full advantage of [ImageSharp](https://github.com/SixLabors/ImageSharp)
|
||||
and manipulate images directly via it's [Processing API](https://docs.sixlabors.com/api/ImageSharp/SixLabors.ImageSharp.Processing.html).
|
||||
and manipulate images directly via its [Processing API](https://docs.sixlabors.com/api/ImageSharp/SixLabors.ImageSharp.Processing.html).
|
||||
|
||||
```csharp
|
||||
// Load an image
|
||||
|
Loading…
x
Reference in New Issue
Block a user