Update documentation

spring-shell-docs/modules/ROOT/pages/appendices/techintro/index.adoc

@@ -1,6 +1,6 @@
 [appendix]
 [#appendix-tech-intro]
-= Techical Introduction
+= Technical Introduction
 :page-section-summary-toc: 1
 
 This appendix contains information for developers and others who would like to know more about how Spring Shell

spring-shell-docs/modules/ROOT/pages/appendices/tui/catalog.adoc

@@ -4,10 +4,10 @@
 
 ifndef::snippets[:snippets: ../../../../../src/test/java/org/springframework/shell/docs]
 
-Catalog application is showing various ways how Terminal UI Framework can be used.
-In this section we discuss how this application works. It can be considered to be
+Catalog application shows various ways how the Terminal UI Framework can be used.
+In this section, we discuss how this application works. It can be considered as
 a reference application as it's using most of the features available and tries
-to follow best practices.
+to follow the best practices.
 
 [[create-scenario]]
 == Create Scenario

spring-shell-docs/modules/ROOT/pages/appendices/tui/index.adoc

@@ -5,9 +5,9 @@
 
 ifndef::snippets[:snippets: ../../test/java/org/springframework/shell/docs]
 
-This is a technical introduction to _UI Framework_.
+This is a technical introduction to the _UI Framework_.
 
-_UI Framework_ is a toolkit to build rich console apps.
+The _UI Framework_ is a toolkit to build rich console apps.
 
 
 

spring-shell-docs/modules/ROOT/pages/appendices/tui/viewdev.adoc

@@ -2,7 +2,7 @@
 = View Development
 :page-section-summary-toc: 1
 
-While a _view_ just need to implement `View` it's usually convenient to just
+While a _view_ just needs to implement `View`, it's usually convenient to just
 use `BoxView` as a parent.
 
 [[register-bindings]]

spring-shell-docs/modules/ROOT/pages/basics/reading.adoc

@@ -5,13 +5,13 @@
 Throughout this documentation, we make references to configuring something by using
 annotations or programmatic examples.
 
-NOTE: There are two annotation models, xref:commands/registration/annotation.adoc[annotations]
-referred to new annotation model, xref:commands/registration/legacyannotation.adoc[legacy annotations]
-referred to old legacy annotation model.
+NOTE: There are two annotation models: the xref:commands/registration/annotation.adoc[annotations] model
+referred to as the new annotation model, and the xref:commands/registration/legacyannotation.adoc[legacy annotations]
+model referred to as the old legacy annotation model.
 
-Old legacy annotation model mostly relates to use of `@ShellMethod` and `@ShellOption` and
-new annotation model relates to use of `@Command`.
+The old legacy annotation model mostly relates to the use of `@ShellMethod` and `@ShellOption` and
+the new annotation model relates to the use of `@Command`.
 
 The programmatic model is how things are actually registered, even if you use annotations.
 
-NOTE: The documentation structure is getting revised to clarify how to provide configurations in separate ways. Thank you for understanding while that work is still in progress. 
+NOTE: The documentation structure is getting revised to clarify how to provide configurations in separate ways.

spring-shell-docs/modules/ROOT/pages/building.adoc

@@ -25,17 +25,17 @@ traditionally been relatively complex process while it may look like
 there's not that much happening as it's all just text.
 
 Remember all those old manual typewriters or matrix printers?
-A character is printed where a cursor is which then need to be moved
+A character is printed then a cursor needs to be moved
 if printing in a different position. In a nutshell that's how current
 terminal emulators work.
 
-To access and understand existing terminal emulator environment better
+To access and understand existing terminal emulators environment better,
 JLine can use native code via its own shared libraries. JLine detects
 which providers are present and then makes a choice which one to use.
 Traditionally there's been 3 providers, `jansi`, `jni` and `jna` which
 should all provide same functionalities.
 
-Our starters can be used to spesifically pick some of these JLine
+Our starters can be used to specifically pick some of these JLine
 providers.
 
 == FFM
@@ -127,7 +127,7 @@ When gradle build is run with `./gradlew nativeCompile` you should get binary
 under `build/native/nativeCompile` directory.
 
 For `maven` use `spring-boot-starter-parent` as parent and you'll get `native`
-profile which can be used to do a compilation. You need to configure metadata repository
+profile which can be used to do a native compilation. You need to configure metadata repository:
 
 [source, xml, subs=attributes+]
 ----

spring-shell-docs/modules/ROOT/pages/commands/alias.adoc

@@ -8,10 +8,9 @@ cases where you want to create a shorter version of a command or going
 through a complete command rename while keeping old one temporarily in
 place.
 
-Format for _alias_ is slighly different than a _command_. When _command_
+The format of _alias_ is slightly different from a _command_. When _command_
 is defined as an array it's concatenated together into a single command.
-When _alias_ is defined as an array it's used to create a separate
-aliases.
+When _alias_ is defined as an array it's used to create separate aliases.
 
 Aliases with a plain `CommandRegistration` is simple and clear as you
 get exactly what you define as there's no "magic" in it.

spring-shell-docs/modules/ROOT/pages/commands/builtin/clear.adoc

@@ -2,5 +2,5 @@
 = Clear
 :page-section-summary-toc: 1
 
-The `clear` command does what you would expect and clears the screen, resetting the prompt
+The `clear` command clears the screen, resetting the prompt
 in the top left corner.

spring-shell-docs/modules/ROOT/pages/commands/builtin/completion.adoc

@@ -2,8 +2,8 @@
 = Completion
 :page-section-summary-toc: 1
 
-The `completion` command set lets you create script files that can be used
-with am OS shell implementations to provide completion. This is very useful when
+The `completion` command lets you create script files that can be used
+with an OS shell implementation to provide completion. This is very useful when
 working with non-interactive mode.
 
-Currently, the only implementation is for bash, which works with `bash` sub-command.
+Currently, the only implementation is for bash, which works with the `bash` sub-command.

spring-shell-docs/modules/ROOT/pages/commands/builtin/help.adoc

@@ -2,9 +2,7 @@
 = Help
 
 Running a shell application often implies that the user is in a graphically limited
-environment. Also, while we are nearly always connected in the era of mobile phones,
-accessing a web browser or any other rich UI application (such as a PDF viewer) may not always
-be possible. This is why it is important that the shell commands are correctly self-documented, and this is where the `help`
+environment. This is why it is important that the shell commands are correctly self-documented, and this is where the `help`
 command comes in.
 
 Typing `help` + `ENTER` lists all the commands known to the shell (including xref:commands/availability.adoc[unavailable] commands)

spring-shell-docs/modules/ROOT/pages/commands/exceptionhandling/annotation.adoc

@@ -6,13 +6,13 @@ ifndef::snippets[:snippets: ../../test/java/org/springframework/shell/docs]
 `@ShellComponent` classes can have `@ExceptionResolver` methods to handle exceptions from component
 methods. These are meant for annotated methods.
 
-The exception may match against a top-level exception being propagated (e.g. a direct IOException
-being thrown) or against a nested cause within a wrapper exception (e.g. an IOException wrapped
-inside an IllegalStateException). This can match at arbitrary cause levels.
+The exception may match against a top-level exception being propagated (e.g. a direct `IOException`
+being thrown) or against a nested cause within a wrapper exception (e.g. an `IOException` wrapped
+inside an `IllegalStateException`). This can match at arbitrary cause levels.
 
 For matching exception types, preferably declare the target exception as a method argument, as
 the preceding example(s) shows. When multiple exception methods match, a root exception match is
-generally preferred to a cause exception match. More specifically, the ExceptionDepthComparator
+generally preferred to a cause exception match. More specifically, the `ExceptionDepthComparator`
 is used to sort exceptions based on their depth from the thrown exception type.
 
 Alternatively, the annotation declaration may narrow the exception types to match, as the
@@ -38,7 +38,7 @@ include::{snippets}/ErrorHandlingSnippets.java[tag=exception-resolver-with-exitc
 
 `@ExceptionResolver` with `void` return type is automatically handled as handled exception.
 You can then also define `@ExitCode` and use `Terminal` if you need to write something
-into console.
+into the console:
 
 [source, java, indent=0]
 ----

spring-shell-docs/modules/ROOT/pages/commands/exceptionhandling/index.adoc

@@ -4,15 +4,15 @@
 
 ifndef::snippets[:snippets: ../../test/java/org/springframework/shell/docs]
 
-Exceptions happen from a user code wether it is intentional or not. This section describes
-how `spring-shell` handles exceptions and gives instructions and best practices how to
+Exceptions happen from a user code whether it is intentional or not. This section describes
+how Spring Shell handles exceptions and gives instructions and best practices on how to
 work with it.
 
-Many command line applications when applicable return an _exit code_ which running environment
-can use to differentiate if command has been executed successfully or not. In a `spring-shell`
-this mostly relates when a command is run on a non-interactive mode meaning one command
-is always executed once with an instance of a `spring-shell`. Take a note that _exit code_
-always relates to non-interactive shell.
+Many command line applications return an _exit code_ which can be used by the
+running environment to differentiate if command has been executed successfully or not.
+In Spring Shell, this mostly relates to when a command is run in a non-interactive mode,
+meaning one command is always executed once with an instance of a `spring-shell`. Take a note
+that _exit code_ always relates to non-interactive shell.
 
 
 

spring-shell-docs/modules/ROOT/pages/commands/exceptionhandling/mappings.adoc

@@ -5,15 +5,15 @@ ifndef::snippets[:snippets: ../../test/java/org/springframework/shell/docs]
 
 Default behaviour of an exit codes is as:
 
-- Errors from a command option parsing will result code of `2`
-- Any generic error will result result code of `1`
-- Obviously in any other case result code is `0`
+- Errors from a command option parsing will result to a code of `2`
+- Any generic error will result to a code of `1`
+- Obviously in any other case will result to a code of `0`
 
 Every `CommandRegistration` can define its own mappings between _Exception_ and _exit code_.
-Essentially we're bound to functionality in `Spring Boot` regarding _exit code_ and simply
+Spring shell uses a similar approach to `Spring Boot` regarding _exit code_ and simply
 integrate into that.
 
-Assuming there is an exception show below which would be thrown from a command:
+Assuming there is an exception shown below which would be thrown from a command:
 
 [source, java, indent=0]
 ----

spring-shell-docs/modules/ROOT/pages/commands/exceptionhandling/resolving.adoc

@@ -5,8 +5,8 @@ ifndef::snippets[:snippets: ../../test/java/org/springframework/shell/docs]
 
 Unhandled exceptions will bubble up into shell's `ResultHandlerService` and then eventually
 handled by some instance of `ResultHandler`. Chain of `ExceptionResolver` implementations
-can be used to resolve exceptions and gives you flexibility to return message to get written
-into console together with exit code which are wrapped within `CommandHandlingResult`.
+can be used to resolve exceptions and gives you the flexibility to return a message to get
+written into the console together with exit code which are wrapped within `CommandHandlingResult`.
 `CommandHandlingResult` may contain a _message_ and/or _exit code_.
 
 [source, java, indent=0]
@@ -14,14 +14,14 @@ into console together with exit code which are wrapped within `CommandHandlingRe
 include::{snippets}/ErrorHandlingSnippets.java[tag=my-exception-resolver-class]
 ----
 
-`CommandExceptionResolver` implementations can be defined globally as bean.
+`CommandExceptionResolver` implementations can be defined globally as beans:
 
 [source, java, indent=0]
 ----
 include::{snippets}/ErrorHandlingSnippets.java[tag=my-exception-resolver-class-as-bean]
 ----
 
-or defined per `CommandRegistration` if it's applicable only for a particular command itself.
+or defined per `CommandRegistration` if it's applicable only to a particular command:
 
 [source, java, indent=0]
 ----
@@ -31,18 +31,18 @@ include::{snippets}/ErrorHandlingSnippets.java[tag=example1]
 NOTE: Resolvers defined with a command are handled before global resolvers.
 
 
-Use you own exception types which can also be an instance of boot's `ExitCodeGenerator` if
-you want to define exit code there.
+You can use your own exception types which can also be instances of Spring Boot's `ExitCodeGenerator`
+if you want to define exit code there:
 
 [source, java, indent=0]
 ----
 include::{snippets}/ErrorHandlingSnippets.java[tag=my-exception-class]
 ----
 
-Some build in `CommandExceptionResolver` beans are registered to handle common
+Some built-in `CommandExceptionResolver` beans are registered to handle common
 exceptions thrown from command parsing. These are registered with _order_
-presedence defined in `CommandExceptionResolver.DEFAULT_PRECEDENCE`.
+precedence defined in `CommandExceptionResolver.DEFAULT_PRECEDENCE`.
 As these beans are used in a given order, `@Order` annotation or `Ordered`
-interface from can be used just like in any other spring app. This
+interface can be used just like in any other Spring app. This
 is generally useful if you need to control your own beans to get used
-either before or after a defaults.
+either before or after default ones.

spring-shell-docs/modules/ROOT/pages/commands/helpoptions.adoc

@@ -5,22 +5,22 @@ ifndef::snippets[:snippets: ../../test/java/org/springframework/shell/docs]
 
 _Spring Shell_ has a build-in `help` command but not all favour getting command help
 from it as you always need to call it with arguments for target command. It's
-common in many cli frameworks for every command having options _--help_ and _-h_
+common in many CLI frameworks for every command having options _--help_ and _-h_
 to print out command help.
 
 Default functionality is that every command will get modified to have options
 _--help_ and _-h_, which if present in a given command will automatically
-short circuit command execution into a existing `help` command regardless
-what other command-line options is typed.
+short circuit command execution into an existing `help` command regardless
+what other command-line options are typed.
 
-Below example shows its default settings.
+The following example shows its default settings:
 
 [source, java, indent=0]
 ----
 include::{snippets}/CommandRegistrationHelpOptionsSnippets.java[tag=defaults]
 ----
 
-It is possible to change default behaviour via configuration options.
+It is possible to change default behaviour via configuration options:
 
 [source, yaml]
 ----
@@ -33,6 +33,6 @@ spring:
       command: help
 ----
 
-NOTE: Commands defined programmationally or via annotations will automatically add
-help options. With annotation model you can only turn things off globally, programmatic
-model gives option to modify settings per command.
+NOTE: Commands defined programmatically or via annotations will automatically add
+help options. With the annotation model you can only turn things off globally, while
+with the programmatic model you can modify settings per command.

spring-shell-docs/modules/ROOT/pages/commands/hidden.adoc

@@ -4,10 +4,10 @@
 ifndef::snippets[:snippets: ../../test/java/org/springframework/shell/docs]
 
 It is possible to _hide_ a command which is convenient in cases where it is not yet ready for
-prime time, is meant for debugging purposes or you have any other reason you dont want to
-advertise its presense.
+prime time, or is meant for debugging purposes or you have any other reason you don't want to
+advertise its presence.
 
-Hidden command can be executed if you know it and its options. It is effectively removed
+A hidden command can be executed if you know it and its options. It is effectively removed
 from:
 
 * Help listing
@@ -15,7 +15,7 @@ from:
 * Command completion in interactive mode
 * Bash completion
 
-Below is an example how to define command as _hidden_. It shows available builder methods
+Below is an example of how to define _hidden_ command. It shows available builder methods
 to define _hidden_ state.
 
 [source, java, indent=0]

spring-shell-docs/modules/ROOT/pages/commands/index.adoc

@@ -5,7 +5,7 @@
 ifndef::snippets[:snippets: ../../test/java/org/springframework/shell/docs]
 
 In this section, we go through an actual command registration and leave command options
-and execution for later in a documentation. You can find more detailed info in
+and execution for a later section in the documentation. You can find more details in
 xref:appendices/techintro/registration.adoc[Command Registration].
 
 

spring-shell-docs/modules/ROOT/pages/commands/interactionmode.adoc

@@ -5,9 +5,9 @@
 ifndef::snippets[:snippets: ../../../../src/test/java/org/springframework/shell/docs]
 
 Command registration can define `InteractionMode` which is used to hide commands
-depending which mode shell is executing. More about that in xref:execution.adoc#using-shell-execution-interactionmode[Interaction Mode].
+depending on which mode the shell is executing in. More about that in xref:execution.adoc#using-shell-execution-interactionmode[Interaction Mode].
 
-You can define it with `CommandRegisration`.
+You can define the interaction mode with `CommandRegisration`:
 
 [source, java, indent=0]
 ----

spring-shell-docs/modules/ROOT/pages/commands/registration/index.adoc

@@ -4,14 +4,13 @@
 
 ifndef::snippets[:snippets: ../../test/java/org/springframework/shell/docs]
 
-There are two different ways to define a command: through an annotation model and
-through a programmatic model. In the annotation model, you define your methods
-in a class and annotate the class and the methods with specific annotations.
-In the programmatic model, you use a more low level approach, defining command
-registrations (either as beans or by dynamically registering with a command catalog).
+There are two different ways to define a command. through an annotation model and through a programmatic model:
 
-Starting from _3.1.x_ a better support for defining commands using
-xref:commands/registration/annotation.adoc[annotations] were added. Firstly because eventually standard
+- In the annotation model, you define your methods in a class and annotate the class and the methods with specific annotations.
+- In the programmatic model, you use a more low level approach, defining command registrations (either as beans or by dynamically registering with a command catalog).
+
+Starting from version _3.1.x_, a better support for defining commands using
+xref:commands/registration/annotation.adoc[annotations] was added. Firstly because eventually standard
 package providing xref:commands/registration/legacyannotation.adoc[legacy annotations] will get deprecated
 and removed. Secondly so that we're able to provide same set of features than using underlying
 `CommandRegistration`. Creating a new annotation model allows us to rethink and modernise that

spring-shell-docs/modules/ROOT/pages/commands/registration/programmatic.adoc

@@ -19,7 +19,7 @@ a new builder so you don't need to worry about its internal state.
 IMPORTANT: Commands registered programmatically automatically
 add _help options_ mentioned in xref:commands/helpoptions.adoc[Help Options].
 
-If bean of this supplier type is defined then auto-configuration
+If a bean of this supplier type is defined then auto-configuration
 will back off giving you an option to redefine default functionality.
 
 [source, java, indent=0]
@@ -28,7 +28,7 @@ include::{snippets}/CommandRegistrationBeanSnippets.java[tag=fromsupplier]
 ----
 
 `CommandRegistrationCustomizer` beans can be defined if you want to centrally
-modify builder instance given you by supplier mentioned above.
+modify builder instance given to you by a supplier as mentioned below:
 
 [source, java, indent=0]
 ----

spring-shell-docs/modules/ROOT/pages/completion.adoc

@@ -18,8 +18,8 @@ methods which takes `CompletionContext` and returns a list of
 `CompletionProposal` instances. `CompletionContext` gives you various
 information about a current context like command registration and option.
 
-NOTE: Generic resolvers can be registered as a beans if those are useful
-for all commands and scenarious. For example existing completion
+NOTE: Generic resolvers can be registered as beans if those are useful
+for all commands and scenarios. For example existing completion
 implementation `RegistrationOptionsCompletionResolver` handles completions
 for a option names.
 

spring-shell-docs/modules/ROOT/pages/components/flow/index.adoc

@@ -21,9 +21,10 @@ include::{snippets}/FlowComponentSnippets.java[tag=snippet1]
 include::example$component-flow-showcase-1.cast[]
 ----
 
-Normal execution order of a components is same as defined with a builder. It's
-possible to conditionally choose where to jump in a flow by using a `next`
-function and returning target _component id_. If this returned id is aither _null_
+NOTE: Normal execution order of a components is same as defined with a builder.
+
+It's possible to conditionally choose where to jump in a flow by using a `next`
+function and returning target _component id_. If this returned id is either _null_
 or doesn't exist flow is essentially stopped right there.
 
 [source, java, indent=0]

spring-shell-docs/modules/ROOT/pages/components/index.adoc

@@ -2,7 +2,7 @@
 = Components
 :page-section-summary-toc: 1
 
-Components are a set of features which are either build-in or something
+Components are a set of features which are either built-in or something
 you can re-use or extend for your own needs. Components in question are
 either built-in _commands_ or UI side components providing higher level
 features within commands itself.

spring-shell-docs/modules/ROOT/pages/customization/commandnotfound.adoc

@@ -3,7 +3,7 @@
 
 ifndef::snippets[:snippets: ../../test/java/org/springframework/shell/docs]
 
-On default a missing command is handled via `CommandNotFoundResultHandler`
+By default, a missing command is handled via `CommandNotFoundResultHandler`
 and outputs a simple message:
 
 [source, text]
@@ -12,7 +12,7 @@ shell:>missing
 No command found for 'missing'
 ----
 
-Internally `CommandNotFoundResultHandler` is using `CommandNotFoundMessageProvider`
+Internally, `CommandNotFoundResultHandler` is using `CommandNotFoundMessageProvider`
 which is a simple function taking a `ProviderContext` and returning a text
 message. Below is an example what a custom message provider might look like.
 

spring-shell-docs/modules/ROOT/pages/customization/logging.adoc

@@ -1,11 +1,11 @@
 [[using-shell-customization-logging]]
 = Logging
 
-On default a _Spring Boot_ application will log messages into a console which
+By default, a _Spring Boot_ application logs messages into a console which
 at minimum is annoying and may also mix output from a shell commands.
-Fortunately there is a simple way to instruct logging changes via boot properties.
+Fortunately, there is a simple way to instruct logging changes via Spring Boot properties.
 
-Completely silence console logging by defining its pattern as an empty value.
+To completely silence console logging, set the console's logging pattern to an empty value:
 
 [source, yaml]
 ----
@@ -14,7 +14,7 @@ logging:
     console:
 ----
 
-If you need log from a shell then write those into a file.
+If you need log from a shell then write those into a file:
 
 [source, yaml]
 ----
@@ -23,7 +23,7 @@ logging:
     name: shell.log
 ----
 
-If you need different log levels.
+If you need different log levels:
 
 [source, yaml]
 ----
@@ -34,8 +34,8 @@ logging:
         shell: debug
 ----
 
-Passing contiguration properties as command line options is not supported but
-you can use any other ways supported by boot, for example.
+Passing configuration properties as command line options is not supported,
+but you can use other ways supported by Spring Boot, for example:
 
 [source, bash]
 ----
@@ -43,5 +43,5 @@ $ java -Dlogging.level.root=debug -jar demo.jar
 $ LOGGING_LEVEL_ROOT=debug java -jar demo.jar
 ----
 
-NOTE: In a GraalVM image settings are locked during compilation which means
+NOTE: In a GraalVM image, settings are locked during compilation which means
       you can't change log levels at runtime.

spring-shell-docs/modules/ROOT/pages/customization/singlecommand.adoc

@@ -5,10 +5,9 @@
 ifndef::snippets[:snippets: ../../test/java/org/springframework/shell/docs]
 
 If your shell application is made for exactly a single purpose having only one
-command it may be beneficial to configure it for this. Property
-`spring.shell.noninteractive.primary-command` if defined will disable all other
-runners than `NonInteractiveShellRunner` and configures it to use
-defined _Primary Command_.
+command, it may be beneficial to configure it for this. If the property
+`spring.shell.noninteractive.primary-command` is defined, it will disable all other
+runners than `NonInteractiveShellRunner` and configures it to use the defined _Primary Command_.
 
 [source, yaml]
 ----
@@ -18,6 +17,6 @@ spring:
       primary-command: mycommand
 ----
 
-For example if you have a command `mycommand` with option `arg`
-it had to be executed with `<shellapp> mycommand --arg hi`, but with above
-setting it can be executed with `<shellapp> --arg hi`.
+For example, if you have a command `mycommand` with option `arg`
+that is expected to be executed with `<shellapp> mycommand --arg hi` in a multi-command app,
+then with the above configuration it can be executed with `<shellapp> --arg hi`.

spring-shell-docs/modules/ROOT/pages/customization/styling.adoc

@@ -4,37 +4,35 @@
 ifndef::snippets[:snippets: ../../../../src/test/java/org/springframework/shell/docs]
 
 Current terminal implementations are rich in features and can usually show
-something else that just plain text. For example a text can be styled to be
+something else that just plain text. For example, a text can be styled to be
 _bold_ or have different colors. It's also common for terminals to be able
-to show various characters from an unicode table like emoji's which are usually
+to show various characters from a unicode table like emoji's which are usually
 used to make shell output more pretty.
 
-Spring Shell supports these via it's theming framework which contains two parts,
-firstly _styling_ can be used to change text type and secondly _figures_ how
-some characters are shown. These two are then combined together as a _theme_.
+Spring Shell supports these via it's theming framework which contains two parts.
+Firstly, _styling_ can be used to change text type and secondly, _figures_ are used
+to customize how characters are shown. These two parts are then combined as a _theme_.
 
-More about _theming_ internals, see xref:appendices/techintro/theming.adoc[Theming].
+For more detail about _theming_ internals, refer to see xref:appendices/techintro/theming.adoc[Theming].
 
-NOTE: Default theme is named `default` but can be change using property
-`spring.shell.theme.name`. Other built-in theme named `dump` uses
-no styling for colors and tries to not use any special figures.
+NOTE: Default theme is named `default` but can be changed using the property
+`spring.shell.theme.name`. There is also another built-in theme named `dump`
+that uses no styling for colors and tries to not use any special figures.
 
-Modify existing style by overriding settings.
+You can modify existing styles and figures by overriding the default settings:
 
 [source, java, indent=0]
 ----
 include::{snippets}/ThemingSnippets.java[tag=custom-style-class]
 ----
 
-Modify existing figures by overriding settings.
-
 [source, java, indent=0]
 ----
 include::{snippets}/ThemingSnippets.java[tag=custom-figure-class]
 ----
 
-To create a new theme, create a `ThemeSettings` and provide your own _style_
-and _figure_ implementations.
+You can also create a new theme, by creating a `ThemeSettings` and provide your own _style_
+and _figure_ implementations:
 
 [source, java, indent=0]
 ----

spring-shell-docs/modules/ROOT/pages/execution.adoc

@@ -60,5 +60,5 @@ default boolean run(String[] args) throws Exception {
 }
 ----
 
-IMPORTANT: This will the main api going forward and other existing methods taking boot's
-`ApplicationArguments` has been deprecated and will be removed in future.
+IMPORTANT: This will be the main api going forward and other existing methods taking boot's
+`ApplicationArguments` have been deprecated and will be removed in a future release.

spring-shell-docs/modules/ROOT/pages/testing/index.adoc

@@ -4,15 +4,14 @@
 
 ifndef::snippets[:snippets: ../../../../src/test/java/org/springframework/shell/docs]
 
-Testing cli application is difficult due to various reasons:
+Testing CLI application is difficult due to various reasons:
 
 - There are differences between OS's.
-- Within OS there may be different shell implementations in use.
-- What goes into a shell and comes out from a shell my be totally
-  different what you see in shell itself due to control characters.
-- Shell may feel syncronous but most likely it is not meaning when
-  someting is written into it, you can't assume next update in
-  in it is not final.
+- Within the same OS there may be different shell implementations in use.
+- What goes into a shell and comes out from a shell may be totally
+  different from what you see in the shell itself due to invisible control characters.
+- The shell may feel synchronous but most likely it is not, meaning when
+  something is written into it, you can't assume next update in it is not final.
 
 NOTE: Testing support is currently under development and will be
       unstable for various parts.

spring-shell-docs/modules/ROOT/pages/testing/settings.adoc

@@ -3,11 +3,11 @@
 
 ifndef::snippets[:snippets: ../../../../src/test/java/org/springframework/shell/docs]
 
-Built in emulation uses terminal width 80 and height 24 on default.
-Changing dimensions is useful if output would span into multiple
-lines and you don't want to handle those cases in a tests.
+Built-in emulation uses terminal width 80 and height 24 by default.
+Changing dimensions is useful if the output would span multiple lines
+and you don't want to handle those cases in a tests.
 
-These can be changed using properties `spring.shell.test.terminal-width`
+These settings can be changed using properties `spring.shell.test.terminal-width`
 or `spring.shell.test.terminal-height`.
 
 [source, java, indent=0]

spring-shell-docs/modules/ROOT/pages/tui/events/eventloop.adoc

@@ -6,16 +6,16 @@ ifndef::snippets[:snippets: ../../../../../src/test/java/org/springframework/she
 
 `EventLoop` is a central place where all eventing will be orchestrated for
 a lifecycle of a component. Orchestration is usually needed around timings
-of redraws and and component state updates.
+of redraws and component state updates.
 
-Everything in an event loop is represented as a Spring Message.
+Everything in an event loop is represented as a Spring Message:
 
 [source, java, indent=0]
 ----
 include::{snippets}/EventLoopSnippets.java[tag=plainevents]
 ----
 
-Selecting key events use a build-in filtering method _keyEvents()_.
+Selecting key events use a built-in filtering method _keyEvents()_.
 
 [source, java, indent=0]
 ----

spring-shell-docs/modules/ROOT/pages/tui/events/index.adoc

@@ -4,4 +4,4 @@
 
 ifndef::snippets[:snippets: ../../../../test/java/org/springframework/shell/docs]
 
-This section contains information about eventing.
+This section contains information about event handling.

spring-shell-docs/modules/ROOT/pages/tui/events/key.adoc

@@ -6,16 +6,16 @@ ifndef::snippets[:snippets: ../../../../../src/test/java/org/springframework/she
 
 Views have their own default bindings which can be changed.
 
-You can subscribe into all key events:
+You can subscribe to all key events:
 
 [source, java, indent=0]
 ----
 include::{snippets}/KeyHandlingSnippets.java[tag=sample]
 ----
 
-`KeyEvent` is a record containing info about a binding coming out
+`KeyEvent` is a record containing information about a binding coming out
 from a terminal.
 
 Some views allow you to register hot keys which are processed before
-normal key handling. More about this can be found from
+normal key handling. More about this can be found in
 xref:appendices/tui/viewdev.adoc#register-bindings[Register Bindings].

spring-shell-docs/modules/ROOT/pages/tui/events/mouse.adoc

@@ -4,12 +4,12 @@
 
 ifndef::snippets[:snippets: ../../../../../src/test/java/org/springframework/shell/docs]
 
-You can subscribe into all mouse events:
+You can subscribe to all mouse events:
 
 [source, java, indent=0]
 ----
 include::{snippets}/MouseHandlingSnippets.java[tag=sample]
 ----
 
-`MouseEvent` is a record wrapping _x_ and _Y_ coordinates and
+`MouseEvent` is a record wrapping _X_ and _Y_ coordinates and
 `org.jline.terminal.MouseEvent` from JLine library.

spring-shell-docs/modules/ROOT/pages/tui/index.adoc

@@ -2,13 +2,13 @@
 = Terminal UI
 :page-section-summary-toc: 1
 
-NOTE: Feature is experimental and subject to breaking changes until foundation
+NOTE: This feature is experimental and is subject to breaking changes until foundation
 and related concepts around framework are getting more stable.
 
 _Terminal UI Framework_ is a toolkit to build rich console apps. This section is
 for those using existing features as is. If you're planning to go deeper possibly
-creating your own components xref:appendices/tui/index.adoc[Terminal UI Appendix]
-provides more detailed documentation.
+by creating your own components, then check xref:appendices/tui/index.adoc[Terminal UI Appendix]
+for more detailed documentation.
 
 TIP: xref:appendices/tui/catalog.adoc[Catalog Sample App] is a good place to
 study a real application.

spring-shell-docs/modules/ROOT/pages/tui/intro/index.adoc

@@ -4,11 +4,11 @@
 
 ifndef::snippets[:snippets: ../../../../../src/test/java/org/springframework/shell/docs]
 
-Lets start with a simple app which prints "hello world" in a view.
+Let's start with a simple app which prints "hello world" in a view.
 [source, java, indent=0]
 ----
 include::{snippets}/TerminalUiSnippets.java[tag=introsample]
 ----
 
 There is not much to see here other than `TerminalUI` is a class handling
-all logic aroung views and uses `View` as it's root view.
+all logic around views and uses `View` as it's root view.

spring-shell-docs/modules/ROOT/pages/tui/intro/terminalui.adoc

@@ -6,8 +6,8 @@ ifndef::snippets[:snippets: ../../../../../src/test/java/org/springframework/she
 `TerminalUI` is a main implementation to drive ui execution logic.
 
 == Create TerminalUI
-You can build `TerminalUI` manually but recommended way is to use `TerminalUIBuilder`
-build is autoconfigured for you and will set needed services.
+You can build `TerminalUI` manually but the recommended way is to use `TerminalUIBuilder`
+which is autoconfigured for you and will set needed services.
 
 [source, java, indent=0]
 ----
@@ -34,8 +34,8 @@ include::{snippets}/TerminalUiSnippets.java[tag=uirun]
 
 == Exiting App
 
-If you want to exit from an app using normal _CTRL-Q_ key combination listen
-events and request _interrupt_.
+If you want to exit from an app using normal _CTRL-Q_ key combination, then
+you need to register a listener for events and request to _interrupt_ the execution.
 
 [source, java, indent=0]
 ----

spring-shell-docs/modules/ROOT/pages/tui/views/app.adoc

@@ -4,9 +4,9 @@
 ifndef::snippets[:snippets: ../../../../../src/test/java/org/springframework/shell/docs]
 
 _AppView_ is a base implementation providing functionality to draw opinionated _application view_.
-Inherits xref:tui/views/box.adoc[].
+This view inherits from xref:tui/views/box.adoc[].
 
-Generic idea is to have menu and status views which typically are xref:tui/views/menubar.adoc[] and
+The generic idea is to have menu and status views which typically are xref:tui/views/menubar.adoc[] and
 xref:tui/views/statusbar.adoc[] respectively. Main content view is then whatever user want to show
 in it.
 

spring-shell-docs/modules/ROOT/pages/tui/views/box.adoc

@@ -5,7 +5,7 @@
 ifndef::snippets[:snippets: ../../../../../src/test/java/org/springframework/shell/docs]
 
 _BoxView_ is a base implementation providing functionality to draw into a
-bounded _Rectancle_. Only direct use of it is its `drawFunction` which
+bounded _Rectangle_. Only direct use of it is its `drawFunction` which
 allows to do simple things without implementing a full custom `View`.
 
 
@@ -15,10 +15,10 @@ include::{snippets}/BoxViewSnippets.java[tag=sample]
 ----
 
 == Customisation
-_BoxView_ as mostly being a base class contains some useful features
-like if it should draw a border and what what are its paddings.
+_BoxView_ is mostly being a base class that contains some useful features
+like if it should draw a border and what are its paddings.
 Border can have a title and its color and focused color can be
-defined. It's also possible to explicitely set background color
+defined. It's also possible to explicitly set a background color
 which will override one from styling.
 
 == Default Bindings

spring-shell-docs/modules/ROOT/pages/tui/views/button.adoc

@@ -5,7 +5,7 @@
 ifndef::snippets[:snippets: ../../../../../src/test/java/org/springframework/shell/docs]
 
 _ButtonView_ is a base implementation providing functionality to draw a button.
-Inherits xref:tui/views/box.adoc[].
+_ButtonView_ inherits from xref:tui/views/box.adoc[].
 
 [source, text]
 ----
@@ -23,7 +23,7 @@ include::{snippets}/ButtonViewSnippets.java[tag=sample]
 
 == Default Bindings
 
-Default _key bindigs_ are:
+Default _key bindings_ are:
 
 .Key
 |===
@@ -34,7 +34,7 @@ Default _key bindigs_ are:
 
 |===
 
-Default _mouse bindigs_ are:
+Default _mouse bindings_ are:
 
 .Mouse
 |===

spring-shell-docs/modules/ROOT/pages/tui/views/dialog.adoc

@@ -5,7 +5,7 @@
 ifndef::snippets[:snippets: ../../../../../src/test/java/org/springframework/shell/docs]
 
 _DialogView_ is a base implementation providing functionality to draw a dialog.
-Inherits xref:tui/views/box.adoc[].
+_DialogView_ inherits from xref:tui/views/box.adoc[].
 
 [source, text]
 ----

spring-shell-docs/modules/ROOT/pages/tui/views/grid.adoc

@@ -4,7 +4,7 @@
 ifndef::snippets[:snippets: ../../../../../src/test/java/org/springframework/shell/docs]
 
 _GridView_ is a special type of view and its purpose is to layout other views
-using a grid layout algorithms. Inherits xref:tui/views/box.adoc[].
+using a grid layout algorithms. _GridView_ inherits from xref:tui/views/box.adoc[].
 
 [source, java, indent=0]
 ----

spring-shell-docs/modules/ROOT/pages/tui/views/index.adoc

@@ -4,4 +4,4 @@
 
 ifndef::snippets[:snippets: ../../../../test/java/org/springframework/shell/docs]
 
-Framework provides a build-in views which are documented below.
+Spring Shell provides a built-in views which are documented below.

spring-shell-docs/modules/ROOT/pages/tui/views/input.adoc

@@ -4,7 +4,7 @@
 ifndef::snippets[:snippets: ../../../../../src/test/java/org/springframework/shell/docs]
 
 _InputView_ is a base implementation providing functionality to draw and modify
-text in a bounded _Rectancle_.
+text in a bounded _Rectangle_.
 
 [source, java, indent=0]
 ----
@@ -32,7 +32,7 @@ Default _view commands_ are:
 
 |===
 
-Default _key bindigs_ are:
+Default _key bindings_ are:
 
 .Key
 |===

spring-shell-docs/modules/ROOT/pages/tui/views/list.adoc

@@ -5,10 +5,10 @@
 ifndef::snippets[:snippets: ../../../../../src/test/java/org/springframework/shell/docs]
 
 _ListView_ is a base implementation providing functionality to draw a list of
-_items_. Inherits xref:tui/views/box.adoc[].
+_items_. _ListView_ inherits from xref:tui/views/box.adoc[].
 
 _ListView<T>_ is typed as its _item_ and can take any object. Further _item_
-processing happens in a _CellFactory_. For conveniance there is a support
+processing happens in a _CellFactory_. For convenience, there is a support
 for generic higher level list feature showing checked states as normal
 _check_ and _radio_ types. Essentially what you can have is a list of
 items which are shown as is, shown where any items can have a checked
@@ -63,7 +63,7 @@ Default _view commands_ are:
 
 |===
 
-Default _key bindigs_ are:
+Default _key bindings_ are:
 
 .Key
 |===
@@ -83,7 +83,7 @@ Default _key bindigs_ are:
 
 |===
 
-Default _mouse bindigs_ are:
+Default _mouse bindings_ are:
 
 .Mouse
 |===

spring-shell-docs/modules/ROOT/pages/tui/views/menu.adoc

@@ -5,10 +5,10 @@
 ifndef::snippets[:snippets: ../../../../../src/test/java/org/springframework/shell/docs]
 
 _MenuView_ is a base implementation providing functionality to draw a menu.
-Inherits xref:tui/views/box.adoc[].
+_MenuView_ inherits from xref:tui/views/box.adoc[].
 
 == Default Bindings
-Default _key bindigs_ are:
+Default _key bindings_ are:
 
 .Key
 |===
@@ -25,7 +25,7 @@ Default _key bindigs_ are:
 
 |===
 
-Default _mouse bindigs_ are:
+Default _mouse bindings_ are:
 
 .Mouse
 |===

spring-shell-docs/modules/ROOT/pages/tui/views/menubar.adoc

@@ -5,7 +5,7 @@
 ifndef::snippets[:snippets: ../../../../../src/test/java/org/springframework/shell/docs]
 
 _MenuBarView_ is a base implementation providing functionality to draw a menu bar.
-Inherits xref:tui/views/box.adoc[].
+_MenuBarView_ inherits from xref:tui/views/box.adoc[].
 
 [source, text]
 ----
@@ -24,7 +24,7 @@ include::{snippets}/MenuBarViewSnippets.java[tag=snippet1]
 ----
 
 == Default Bindings
-Default _key bindigs_ are:
+Default _key bindings_ are:
 
 .Key
 |===
@@ -38,7 +38,7 @@ Default _key bindigs_ are:
 
 |===
 
-Default _mouse bindigs_ are:
+Default _mouse bindings_ are:
 
 .Mouse
 |===

spring-shell-docs/modules/ROOT/pages/tui/views/progress.adoc

@@ -4,25 +4,25 @@
 
 ifndef::snippets[:snippets: ../../../../../src/test/java/org/springframework/shell/docs]
 
-_ProgressView_ is a base implementation providing functionality to draw a progress info.
-Inherits xref:tui/views/box.adoc[].
+_ProgressView_ is a base implementation providing functionality to draw a progress information.
+_ProgressView_ inherits from xref:tui/views/box.adoc[].
 
-_ProgressView_ draws its content using concepts described below
+_ProgressView_ draws its content using concepts described below:
 
 * _ProgressState_ contains various info about a runtime state
-** _tickStart_ Lower bound of tick value
-** _tickEnd_ Upper bound of tick value
-** _tickValue_ Current tick value
-** _running_ Running state, either true or false
-** _startTime_ Start time in millis when progress was started
-** _updateTime_ Last known time in millis when progress has updated
+** _tickStart_: Lower bound of tick value
+** _tickEnd_: Upper bound of tick value
+** _tickValue_: Current tick value
+** _running_: Running state, either true or false
+** _startTime_: Start time in millis when progress was started
+** _updateTime_: Last known time in millis when progress has updated
 * _ProgressContext_ is a context used with _ProgressViewItem_
-** _description_ The description given to progress
-** _state_ The _ProgressState_
-** _view_ The owning _ProgressView_
-** _spinner_ The _Spinner_ representation used with _ProgressView_
+** _description_: The description given to progress
+** _state_: The _ProgressState_
+** _view_: The owning _ProgressView_
+** _spinner_: The _Spinner_ representation used with _ProgressView_
 ** Other methods to help with item drawing
-* _ProgressViewItem_ is a representation of a cell used in _ProgressView_
+* _ProgressViewItem_: is a representation of a cell used in _ProgressView_
 
 There are few build-in items namely `text`, `spinner` and `percent`.
 
@@ -42,7 +42,7 @@ include::example$tui-progress-1.cast[]
 
 == Customisation
 
-Here's some examples for various customisations:
+Here are some examples for various customisations:
 
 [source, java, indent=0]
 ----

spring-shell-docs/modules/ROOT/pages/tui/views/statusbar.adoc

@@ -4,7 +4,7 @@
 ifndef::snippets[:snippets: ../../../../../src/test/java/org/springframework/shell/docs]
 
 _StatusBarView_ is a base implementation providing functionality to draw a status bar.
-Inherits xref:tui/views/box.adoc[].
+_StatusBarView_ inherits from xref:tui/views/box.adoc[].
 
 [source, text]
 ----
@@ -20,15 +20,15 @@ You can create a simple status bar with an item:
 include::{snippets}/StatusBarViewSnippets.java[tag=simple]
 ----
 
-Constructor can take array form which allows to lay out simple
-item definitions in a _dsl_ style.
+The constructor can take array form which allows to lay out simple
+item definitions in a _dsl_ style:
 
 [source, java, indent=0]
 ----
 include::{snippets}/StatusBarViewSnippets.java[tag=viaarray]
 ----
 
-Items support runnable actions which generally as executed when
+Items support runnable actions which generally are executed when
 item is selected. It can also get attached to a hot key.
 
 [source, java, indent=0]