typo: promt ->prompt

Pkg3.md

@@ -67,7 +67,7 @@ An **environment** catures a specific set of package and library versions and th
 
 In Pkg2, package operations like `Pkg.add`, `Pkg.rm`, and `Pkg.update` are somewhat inconsistent about whether they operate on the current running Julia process or not. This is because different actions have different feasibility with respect to the current session: it's possible to install or update a package before it is loaded, but it is impossible to remove or update an already-loaded package. Thus, performing operations on the set of available packages *in general* requires a restart of the process before it can take effect, but installing and then loading a new package without restarting the current process is common and useful.
 
-In Pkg3, general operations on environments are not done in the Julia process using an environment. Instead, they are done through a standalone process, which (although it is implemented in Julia) does not operate within the environment that it manipulates. The most common operation, however – installing and loading a new package – will typically be done implicitly and automatically in an interactive Julia session. In other words, when the user does `using XYZ` in the REPL, if  `XYZ` is not installed, the REPL will promt the user if they want to install `XYZ` and its dependencies, and if they agree, it will install and then load it. Since this is the most common operation it can be done without restarting the current Julia process, it makes sense that it be handled specially. When the user wants to remove package or update packages from an environment, they will instead invoke an external package management mode (`julia --pkg`?), which makes it clear that changes will not affect any currently running Julia sessions. The impact on usability is a strict improvement:
+In Pkg3, general operations on environments are not done in the Julia process using an environment. Instead, they are done through a standalone process, which (although it is implemented in Julia) does not operate within the environment that it manipulates. The most common operation, however – installing and loading a new package – will typically be done implicitly and automatically in an interactive Julia session. In other words, when the user does `using XYZ` in the REPL, if  `XYZ` is not installed, the REPL will prompt the user if they want to install `XYZ` and its dependencies, and if they agree, it will install and then load it. Since this is the most common operation it can be done without restarting the current Julia process, it makes sense that it be handled specially. When the user wants to remove package or update packages from an environment, they will instead invoke an external package management mode (`julia --pkg`?), which makes it clear that changes will not affect any currently running Julia sessions. The impact on usability is a strict improvement:
 
 - Adding packages and loading them is easier since one simply does `using XYZ` and answers interactive prompts.
 - Removing and upgrading packages is no less difficult since it previously required restarting the current Julia process anyway, and is less confusing since the requirement to restart is explict since running a separate process clearly doesn't affect the current one.
@@ -95,7 +95,7 @@ By default, Julia runs in open mode. When testing or deploying, however, Julia s
 
 The environment specification of a project is split into three files: `Config.toml`, `Manifest.toml`, and `Local.toml`. (Each file name may also be prefixed with `Julia`, in which case the non-prefixed file, if it exists, is ignored.) The purpose of these files is to separate the environment into three parts:
 
-- `Config.toml`: manual configuration, checked into version control (intput)
+- `Config.toml`: manual configuration, checked into version control (input)
 - `Manifest.toml`: generated information, checked into version control (output)
 - `Local.toml`: generated information, not checked into version control (by product)