NIT Improve some website docs (#1243)

Author: BlackAnubis7

website/docs/_scala-ecosystem.md

@@ -4,7 +4,7 @@ sidebar_position: 31
 ---
 
 :::note
-This page is interested in the future of Scala ecosystem.
+This page concerns the future of the Scala ecosystem.
 
 If you just want to learn Scala CLI just head out to the [Commands section](./commands/basics.md)
 :::

website/docs/commands/basics.md

@@ -3,7 +3,7 @@ title: Basics
 sidebar_position: 3
 ---
 
-Scala CLI is a command line tool that executes a given command on the inputs it’s provided with a given [configuration](../guides/configuration.md) to produce a result.
+Scala CLI is a command line tool that executes a given command on the inputs it’s provided with, using a given [configuration](../guides/configuration.md) to produce a result.
 
 The most important commands are:
 
@@ -22,10 +22,10 @@ The `scala-cli` CLI commands accept input in a number of ways, most notably:
 
 - as source files
 - as one or several directories that contain source files
-- as URLs, pointing to sources
+- as URLs pointing to sources
 - by processing source code via piping or process substitution
 
-Note that all of these input formats can used alongside each other.
+Note that all of these input formats can be used alongside each other.
 
 ## Source files
 
@@ -35,7 +35,7 @@ Scala CLI accepts the following types of source code:
 - `.sc` files, containing Scala scripts (see more in [Scripts guide](../guides/scripts.md))
 - `.java` files, containing Java code
 
-This example shows the simplest input format.
+The following example shows the simplest input format.
 First, create a source file:
 
 ```scala title=Hello.scala
@@ -86,7 +86,7 @@ compilation will fail. `scala-cli` compiles only the files it’s given.
 :::
 
 While this is *very* convenient for projects with just a few files, passing many files this way can be cumbersome and error-prone.
-For larger projects, directories can help.
+In the case of larger projects, passing whole directories can help.
 
 
 ## Directories
@@ -108,7 +108,7 @@ object Hello {
 }
 ```
 
-For this case, run all the source code files in `my-app` by supplying the directory name:
+In this case, you can run all the source code files in `my-app` by supplying the directory name:
 
 ```bash
 scala-cli my-app
@@ -152,7 +152,7 @@ scala-cli https://gist.github.com/alexarchambault/7b4ec20c4033690dd750ffd601e540
 
 ### Zip archive
 
-`scala-cli` accepts input via `zip` archive path
+`scala-cli` accepts inputs via a `zip` archive path.
 It unpacks the archive and runs it:
 
 ```scala titleHello.scala
@@ -194,7 +194,7 @@ More details in the [Piping guide](../guides/piping.md).
 
 ## Scala CLI version
 
-`scala-cli` can also run another Scala CLI version, which can be helpful to test unreleased yet Scala CLI functionality.
+`scala-cli` can also run another Scala CLI version, which can be helpful to test unreleased Scala CLI functionalities.
 :::warning
 Running another Scala CLI version might be slower because it uses JVM-based Scala CLI launcher.
 :::

website/docs/commands/clean.md

@@ -3,4 +3,4 @@ title: Clean
 sidebar_position: 16
 ---
 
-The `clean` command deletes all of the files that are generated by `scala-cli`. This includes the `.scala-build` directory where Scala CLI writes outputs and stores its caches.
+The `clean` command deletes all of the files generated by `scala-cli`. This includes the `.scala-build` directory where Scala CLI writes outputs and stores its caches, and `.bsp/scala-cli.json` file which contains details for the BSP connection (necessary for importing a Scala CLI build to your IDE of choice).

website/docs/commands/compile.md

@@ -17,8 +17,8 @@ scala-cli compile Hello.scala
 ```
 
 Note that most Scala CLI commands automatically compile your code, if necessary.
-The `compile` command is useful if you'd like to check that your code compiles,
-or know of compilation warnings, without running it or packaging it.
+The `compile` command is useful if you want to check that your code compiles
+(or to see the compilation warnings, if any occur) without running it or packaging it.
 
 The most common `compile` options are shown below.
 For a full list of options, run `scala-cli compile --help`, or check the options linked in the
@@ -87,7 +87,7 @@ For compiling with an specific nightly build, you have the full version for:
 scala-cli Hello.scala -S 2.13.9-bin-4505094
 ```
 
-For adding this inside scala files with [using directives](../guides/using-directives.md), use:
+For setting this inside scala files, use [`using` directives](../guides/using-directives.md):
 
 ```scala
 //> using scala "2.nightly"

website/docs/commands/fmt.md

@@ -22,15 +22,15 @@ scala-cli fmt --check
 
 ### Scalafmt version and dialect
 
-Scala CLI `fmt` command supports passing the `scalafmt` **version** and **dialect** directly from the command line, using respectively the `--scalafmt-dialect` and `--scalafmt-version` options:
+Scala CLI `fmt` command supports passing the `scalafmt` **version** and **dialect** directly from the command line, using the `--scalafmt-dialect` and `--scalafmt-version` options respectively:
 ```
 scala-cli fmt --scalafmt-dialect scala3 --scalafmt-version 3.5.8
 ```
-You can skip passing either of those, which will make Scala CLI to infer a default value:
+You can skip passing either of those, which will make Scala CLI infer a default value:
 - If a `.scalafmt.conf` file is present in the workspace and it has the field defined, the value will be read from there, unless explicitly specified with Scala CLI options.
-- Otherwise, the default `scalafmt` **version** will be the latest one used by your Scala CLI version (so it is subject to change when updating Scala CLI). The default **dialect** will be inferred based on Scala version (defined explicitly by `-S` option, or default version if option would not be passed).
+- Otherwise, the default `scalafmt` **version** will be the latest one used by your Scala CLI version (so it is subject to change when updating Scala CLI). The default **dialect** will be inferred based on the Scala version (defined explicitly by `-S` option, or default version if the option is not passed).
 
-It is possible to pass the configuration as a string directly from the command line, using `--scalafmt-conf-str` option. If the configuration is passed this way, Scala CLI will behave exactly the same as if it would find the specified configuration in a `.scalafmt.conf` file in the workspace.
+It is possible to pass the configuration as a string directly from the command line, using `--scalafmt-conf-str` option. If the configuration is passed this way, Scala CLI will behave exactly the same as if it found the specified configuration in the `.scalafmt.conf` file in the workspace.
 
 #### Example 1
 
@@ -43,7 +43,7 @@ runner.dialect = scala212
 scala-cli fmt --scalafmt-dialect scala213
 ```
 
-For above setup `fmt` will use:
+For the setup above, `fmt` will use:
 - `version="3.5.8"` from the file
 - `dialect=scala213`, because passed `--scalafmt-dialect` option overrides dialect found in the file
 
@@ -57,7 +57,7 @@ version = "2.7.5"
 scala-cli fmt --scalafmt-version 3.5.8
 ```
 
-For above setup `fmt` will use:
+For the setup above, `fmt` will use:
 - `version="3.5.8"`, because passed `--scalafmt-version` option overrides version from the file
 - `dialect=scala3`, because dialect is neither passed as an option nor is it present in the configuration file, so it is inferred based on the Scala version; the Scala version wasn't explicitly specified in the command either, so it falls back to the default Scala version - the latest one, thus the resulting dialect is `scala3`. 
 
@@ -171,5 +171,5 @@ If the `--save-scalafmt-conf` option is passed, then `fmt` command behaves as fo
 - In the **third** case `fmt` creates a `.scalafmt.conf` file in the current workspace directory, writes [inferred](/docs/commands/fmt#scalafmt-version-and-dialect) version and dialect into it and uses it to run `scalafmt`.
 
 :::note
-If the configuration is passed in the `--scalafmt-conf-str` option, Scala CLI will behave exactly the same as if it would find the specified configuration in a `.scalafmt.conf` file in the workspace.
+If the configuration is passed in the `--scalafmt-conf-str` option, Scala CLI will behave exactly the same as if it found the specified configuration in a `.scalafmt.conf` file in the workspace.
 :::

website/docs/commands/misc/config.md

@@ -5,7 +5,7 @@ sidebar_position: 1
 
 import {ChainedSnippets} from "../../../src/components/MarkdownComponents.js";
 
-The `config` sub-command allows to get and set various configuration values, used by
+The `config` sub-command makes it possible to get and set various configuration values, used by
 other Scala CLI sub-commands.
 
 Examples of use:

website/docs/commands/misc/pgp.md

@@ -7,7 +7,7 @@ The `pgp` sub-commands are low-level commands, exposing the PGP capabilities of
 Scala CLI. These capabilities are used in the `publish` and `publish setup` commands
 in particular.
 
-These commands allow to
+These commands make it possible to
 - create PGP keys with `pgp create`
 - get a key fingerprint with `pgp key-id`
 - push them to / pull them from key servers with `pgp push` / `pgp pull`

website/docs/commands/package.md

@@ -18,9 +18,9 @@ The `package` command can package your Scala code in various formats, such as:
 The default package format writes a *lightweight launcher JAR*, like the "bootstrap" JAR files [generated by coursier](https://get-coursier.io/docs/cli-bootstrap#bootstraps).
 These JARs tend to have a small size (mostly containing only the byte code from your own sources),
 can be generated fast,
-and download their dependencies upon first launch, via [coursier](https://get-coursier.io).
+and download their dependencies upon first launch via [coursier](https://get-coursier.io).
 
-These can be copied onto other machines, and will run fine there.
+Such JARs can be copied to other machines, and will run fine there.
 Their only requirement is that the `java` command needs to be available in the `PATH`:
 
 ```scala title=Hello.scala
@@ -101,11 +101,11 @@ Hello
 
 Scala CLI can create an executable application and package it into a docker image.
 
- For example, here’s an application that will be executed in a docker container:
+For example, here’s an application that will be executed in a docker container:
 
 ```scala title=HelloDocker.scala
 object HelloDocker extends App {
-    println("Hello from Docker")
+  println("Hello from Docker")
 }
 ```
 
@@ -133,7 +133,7 @@ Hello from Docker
 -->
 
 You can also create Docker images for Scala.js and Scala Native applications.
-This command shows how to create a Docker image (`--docker`) for a Scala.js (`--js`) application:
+The following command shows how to create a Docker image (`--docker`) for a Scala.js (`--js`) application:
 
 ```bash
 scala-cli package --js --docker HelloDocker.scala --docker-image-repository hello-docker
@@ -145,7 +145,7 @@ docker run hello-docker:latest
 
 Packaging Scala Native applications to a Docker image is only supported on Linux.
 
- This command shows how to do that:
+The following command shows how to do that:
 
 ```bash ignore
 scala-cli package --native --docker HelloDocker.scala --docker-image-repository hello-docker
@@ -163,7 +163,7 @@ scala-cli package --docker HelloDocker.scala --docker-from openjdk:11 --docker-i
 
 ## Scala.js
 
-Packaging Scala.js applications results in a `.js` file, that can be run with `node`:
+Packaging Scala.js applications results in a `.js` file, which can be run with `node`:
 
 <!-- TODO: add something js specific -->
 
@@ -185,12 +185,12 @@ Hello
 -->
 
 
-Note that Scala CLI doesn't offer to link the resulting JavaScript with linkers, such as Webpack (yet).
+Note that Scala CLI doesn't offer the ability to link the resulting JavaScript with linkers, such as Webpack (yet).
 
 ## Native image
 
 [GraalVM native image](https://www.graalvm.org/22.0/reference-manual/native-image/)
-allows to build native executables out of JVM applications. It can
+makes it possible to build native executables out of JVM applications. It can
 be used from Scala CLI to build native executables for Scala applications.
 
 <!-- clear -->
@@ -217,8 +217,8 @@ using the [JVM management capabilities of coursier](https://get-coursier.io/docs
 
 Several options can be passed to adjust the GraalVM version used by Scala CLI:
 - `--graalvm-jvm-id` accepts a JVM identifier, such as `graalvm-java17:22.0.0` or `graalvm-java17:21` (short versions accepted).
-- `--graalvm-java-version` allows to specify only a target Java version, such as `11` or `17` (note that only specific Java versions may be supported by the default GraalVM version that Scala CLI picks)
-- `--graalvm-version` allows to specify only a GraalVM version, such as `22.0.0` or `21` (short versions accepted)
+- `--graalvm-java-version` makes it possible to specify only a target Java version, such as `11` or `17` (note that only specific Java versions may be supported by the default GraalVM version that Scala CLI picks)
+- `--graalvm-version` makes it possible to specify only a GraalVM version, such as `22.0.0` or `21` (short versions accepted)
 
 ## Scala Native
 
@@ -369,7 +369,7 @@ Instead of passing the `package` options directly from bash, it is possible to p
 
 ### packaging.packageType
 
-This using directive allows to define the type of the package generated by the `package` command. For example:
+This using directive makes it possible to define the type of the package generated by the `package` command. For example:
 
 ```
 //> using packaging.packageType "assembly"
@@ -379,10 +379,10 @@ Available types: `assembly`, `raw-assembly`, `bootstrap`, `library`, `source`, `
 
 ### packaging.output
 
-This using directive allows to define the destination path of the package generated by the `package` command. For example:
+This using directive makes it possible to define the destination path of the package generated by the `package` command. For example:
 
 ```
 //> using packaging.output "foo"
 ```
 
-This using directive allows to create a package named `foo` inside the current directory.
+The using directive above makes it possible to create a package named `foo` inside the current directory.

website/docs/commands/run.md

@@ -81,7 +81,7 @@ object Utils {
 }
 ```
 
-`scala-cli` takes into account and compiles `Utils.scala`.
+`scala-cli` takes it into account and compiles `Utils.scala`.
 
 ```bash
 scala-cli Main.scala
@@ -114,7 +114,7 @@ scala-cli run Hello.scala  --watch
 ```
 ### Watch mode - restart
 
-`--restart` mode runs your application in the background and automatically restart it upon any change:
+`--restart` mode runs your application in the background and automatically restarts it upon any change:
 
 ```bash ignore
 scala-cli run Hello.scala --restart

website/docs/commands/setup-ide.md

@@ -14,13 +14,13 @@ But if you want to, invoke `setup-ide` like:
 scala-cli setup-ide . --scala 2.13
 ```
 
-Keep in mind that if you change any of those options, you may need to restart your IDE, or re-import your project.
+Keep in mind that if you change any of these options, you may need to restart your IDE, or re-import your project.
 
 ### IDE support internals
 
 After invoking `setup-ide`, two files should be generated:
 - `.bsp/scala-cli.json`
-- `.scala/ide-options-v2.json`
+- `.scala-build/ide-options-v2.json`
 
 The first file is specifically created for Build Server Protocol (BSP) support in your IDE.
 BSP is supported by VS Code (via the Metals extension) and IntelliJ (with the Scala plugin), and defines the way in which IDEs gather information about the project you are working on.