doc(uri): add space to formatting in the README

README.md

@@ -17,21 +17,31 @@ To bridge this gap, Eka's working design incorporates:
 
 ## The Atom URI
 
-In order to provide a polished and simple UI, atom's have a convenient URI format which naturally help address them. Conceptually, an atom URI is just a URL with a configurable shortener mechanism (aliases), sane defaults to help elide the scheme in many scenarios, and a custom extension at the end to address atoms unambiguously; abstractly expressed as:
+In order to provide a polished and simple UI, atom's have a convenient URI format which naturally help address them.
+
+Conceptually, an atom URI is just a URL with a configurable shortener mechanism (aliases), sane defaults to help elide the scheme in many scenarios, and a custom extension at the end to address atoms unambiguously; abstractly expressed as:
 ```
 [scheme://][[user[:pass]@][url-alias:][url-fragment::]atom-id[@version]
 ```
 
 ### Concrete Examples
 
-Below are some examples of atom URIs, with the URL portion expanded to demonstrate the alias functionality. Aliases are user settable via the `eka.toml` file, and some convenient defaults (`gh -> github.com`) are built in. Atom's themselves, are abstracted to a flat namespace within the store, regardless of its physical location. To demonstrate this, in the following examples, say we have an atom manifest in your git repo at `foo/bar/[email protected]` which species the `atom.id` in the TOML as `my-atom`:
-
-* `gh:owner/repo::my-atom@^1 -> https://github.com/owner/repo`: the `@^1` is a semantic version request
-* `gl:owner/repo::my-atom -> https://gitlab.com/owner/repo`: no version (`@`) means fetch the latest
-* `org:repo::[email protected] -> https://github.com/work-org/repo`: assuming the user sets `org = "gh:work-org"` in the `eka.toml`. Notice that users can refer to other aliases in the config to "compose" them.
-* `git@gh:owner/repo::my-atom -> ssh://[email protected]:owner/repo`: a URL with a user specification defaults to ssh
-* `git:pass@gh:owner/repo::my-atom -> https://[email protected]/owner/repo`: a user:pass combo defaults to https
-* `http://gh:owner/repo::my-atom -> http://github.com/owner/repo`: it is possible to explicate the scheme where necessary, but the heuristics try to make this uncommon
+Below are some examples of atom URIs, with the URL portion expanded to demonstrate the alias functionality. Aliases are user settable via the `eka.toml` file, and some convenient defaults (`gh -> github.com`) are built in.
+
+Atom's, themselves, are abstracted to a flat namespace within the store, regardless of its physical location. To demonstrate this, in the following examples, say we have an atom manifest in the git repo at `foo/bar/[email protected]` which species the `atom.id` in the TOML as `my-atom`:
+
+* `gh:owner/repo::my-atom@^1 -> https://github.com/owner/repo`
+  * the `@^1` is a semantic version request
+* `gl:owner/repo::my-atom -> https://gitlab.com/owner/repo`
+  * no version (`@`) means fetch the latest
+* `org:repo::[email protected] -> https://github.com/work-org/repo`
+  * assuming the user sets `org = "gh:work-org"` in the `eka.toml`. Notice that users can refer to other aliases in the config to "compose" them.
+* `git@gh:owner/repo::my-atom -> ssh://[email protected]:owner/repo`
+  * a URL with a user specification defaults to ssh
+* `git:pass@gh:owner/repo::my-atom -> https://[email protected]/owner/repo`
+  * a user:pass combo defaults to https
+* `http://gh:owner/repo::my-atom -> http://github.com/owner/repo`
+  * it is possible to explicate the scheme where necessary, but the heuristics try to make this uncommon
 
 ## Usage