Fix spacing

crates/arti-client/src/client.rs

@@ -123,7 +123,7 @@ pub enum DormantMode {
 pub struct StreamPrefs {
     /// What kind of IPv6/IPv4 we'd prefer, and how strongly.
     ip_ver_pref: IpVersionPreference,
-    /// How should we isolate connection(s) ?
+    /// How should we isolate connection(s)?
     isolation: StreamIsolationPreference,
     /// Whether to return the stream optimistically.
     optimistic_stream: bool,

crates/tor-linkspec/README.md

@@ -10,7 +10,7 @@ describe how to connect to Tor relays.
 When describing the location of a Tor relay on the network, the
 Tor protocol uses a set of "link specifiers", each of which
 corresponds to a single aspect of the relay's location or
-identity—such as its IP address and port, its Ed25519 identity
+identity — such as its IP address and port, its Ed25519 identity
 key, its (legacy) RSA identity fingerprint, or so on.  This
 crate's [`LinkSpec`] type encodes these structures.
 

crates/tor-socksproto/README.md

@@ -45,7 +45,7 @@ for two reasons:
    of the individual handshakes that most other SOCKS
    implementations don't expose.  (For example, if we are told to
    connect to a raw IP address, the type of the handshake can help
-   us guess whether that IP address came from a DNS response–in
+   us guess whether that IP address came from a DNS response – in
    which case we should warn about a possible DNS leak.)
 
 Currently, `tor-socksproto` does no networking code: it _only_

doc/Errors.md

@@ -28,7 +28,7 @@ Everywhere else besides arti_error::Error, we try to make our error types follow
  * All should implement Clone, Display, Error, Debug, Send, Sync, 'static.
  * When we wrap an inner error, we always include context information describing what was happening when the inner error occurred.  This means that we should usually not `impl From<TheirInner> for MyError`.
  * Whenever appropriate, we have a `pub fn kind(&self) -> ErrorKind` function.
- * When a  public function can fail for a number of reasons that are much more limited than the crate's entire Error type, we should consider give that function its own Error type.
+ * When a public function can fail for a number of reasons that are much more limited than the crate's entire Error type, we should consider giving that function its own Error type.
  * We use `Box<>` as needed to keep the size of the enumeration fairly small.
  * We allow more instability in these types than we allow in arti_client: these types should be inaccessible from the arti_client when "error-details" is not enabled.
 
@@ -84,7 +84,7 @@ enum ErrorDetail {
 }
 
 #[cfg(feature("error-details"))]
-pub use ErrorDetail; //This becomes public only if we have 
+pub use ErrorDetail; // This becomes public only if we have
 
 impl std::error::Error for ErrorDetail { ... }
 
@@ -151,7 +151,7 @@ We _do_ expose the entire error enumeration from these crates.  That means we mi
 
 **TODO**: should be documented somewhere! perhaps more generally ("tor-* crates are more unstable")
 
-#### Who is responsible for putting calling parameters into the error ?
+#### Who is responsible for putting calling parameters into the error?
 
 Eg, tor-chanmgr has this:
 
@@ -175,7 +175,7 @@ For example, when tor-circmgr calls `build_channel`, it is tor-circmgr which is
 
 #### Describing the error type
 
-When a problem is reported, different error types should generally produce different messages.  Where should this be done ?
+When a problem is reported, different error types should generally produce different messages.  Where should this be done?
 
 Answer: the place where the type is embedded.  For example: