Minor cleanups.

There seem to be an unending number of them!

Signed-off-by: Dan Hackney <dan@haxney.org>

1 files changed, 30 insertions, 29 deletions

diff --git a/README b/README
index 40518c2..4cba528 100644
--- a/README
+++ b/README
@@ -16,7 +16,7 @@ The Uzbl project was started as an attempt to resolve this.
 * Uses WebKitGtk+ for rendering and network interaction (libsoup). CSS, JavaScript, and plugin support come for free.
 * Provides interfaces to get data in (commands/configuration) and out (events): stdin/stdout/fifo/Unix sockets.
 * You see a WebKit view and (optionally) a statusbar which gets popuplated externally.
-* No built-in means for url changing, loading/saving of bookmarks, saving history, keybinds, downloads, etc.
+* No built-in means for URL changing, loading/saving of bookmarks, saving history, keybinds, downloads, etc.
 * Extra functionality: many sample scripts come with it. More are available on the [Uzbl wiki](http://www.uzbl.org/wiki/scripts) or you can write them yourself.
 * Entire configuration/state can be changed at runtime.
 * Uzbl keeps it simple, and puts **you** in charge.
@@ -25,17 +25,17 @@ The Uzbl project was started as an attempt to resolve this.
 
 * Uses a set of scripts (mostly Python) that will fit most people, so things work out of the box; yet plenty of room for customization.
 * Brings everything you expect: URL changing, history, downloads, form filling, link navigation, cookies, event management etc. However: one page per instance.
-* Advanced, customizable keyboard interface with support for modes, modkeys, multichars, variables (keywords) etc. (eg you can tweak the interface to be vim-like, emacs-like or any-other-program-like).
+* Advanced, customizable keyboard interface with support for modes, modkeys, multichars, variables (keywords) etc. (eg you can tweak the interface to be Vi-like, Emacs-like or any-other-program-like).
 * Adequate default configuration.
 * Focus on plaintext storage for your data and configs in simple, parseable formats and adherence to the XDG basedir spec.
 * Visually, similar to `uzbl-core` except that the statusbar contains useful information. One window per webpage.
 
 #### uzbl-tabbed: wraps around uzbl-browser and multiplexes it
 
-* Spawns one window containing multiple tabs, each tab containing a full embedded uzbl-browser.
-* Ideal as a quick and simple solution to manage multiple uzbl-browser instances without getting lost.
+* Spawns one window containing multiple tabs, each tab containing a full embedded `uzbl-browser`.
+* Ideal as a quick and simple solution to manage multiple `uzbl-browser` instances without getting lost.
 
-Throughout the documentation, when referring to Uzbl we mean `uzbl-core`, unless otherwise specified.
+Throughout the documentation, when referring to `uzbl` we mean `uzbl-core`, unless otherwise specified.
 
 ### CONFIGURATION / CONTROL:
 
@@ -46,25 +46,24 @@ There are several interfaces to interact with Uzbl:
 * `uzbl --config <filename>`: `<filename>` will be read line by line, and the commands in it will be executed. Useful to configure Uzbl at startup. If you have a file in `$XDG_CONFIG_HOME/uzbl/config` (this expands to `~/.config/uzbl/config` on most systems), it will be automatically recognized.
 * `stdin`: to write commands into `stdin`, use `--config -` (or `-c -`).
 * Interactive: you can enter commands (and bind them to shortcuts, even at runtime)
-  By default, the behaviour is modal (vi style):
+  By default, the behaviour is modal (Vi style):
 
   - command mode: every keystroke is interpreted to run commands
   - insert mode: keystrokes are not interpreted so you can enter text into html forms
 
-  There is also support for "chained" commands (multiple characters long) (with backspace/esc shortcuts), and keyworded commands. Also you can have incremental matching on commands or match after pressing return.  (see sampleconfig for more info)
+  There is also support for "chained" commands (multiple characters long), and keyworded commands. Also you can have incremental matching on commands or match after pressing return. See the sample configuration file for more info.
 
-  Also, copy paste works when typing commands:
+  Also, copy and paste works when typing commands:
 
-  - insert (paste X cliboard)
-  - shift insert (paste primary selection buffer)
+  - `insert` (paste X cliboard)
+  - `shift insert` (paste primary selection buffer)
 
-* FIFO & socket file: If enabled by setting their paths through one of the above means, you can have socket and fifo files available which are very useful to programmatically control `uzbl` (from scripts etc).
+* FIFO & socket files: If enabled by setting their paths through one of the above means, you can have socket and fifo files available which are very useful to programmatically control `uzbl` (from scripts etc).
 
-  - The advantage of the fifo is you can write plaintxt commands to it, but it's half duplex only (`uzbl` cannot send a response to you).
-  - The socket is full duplex but you need a socket-compatible wrapper such as socat to work with it.
-  - For example: `echo <command> | socat - unix-connect:<socketfile>`
+  - The advantage of the FIFO is you can write plaintext commands to it, but it's half duplex only (`uzbl` cannot send a response to you).
+  - The socket is full duplex but you need a socket-compatible wrapper such as `socat` to work with it. For example: `echo <command> | socat - unix-connect:<socketfile>`
 
-When uzbl forks a new instance (eg "open in new window") it will use the same commandline arguments (eg the same `--config <file>`), except `--uri` and `--name`. If you made changes to the configuration at runtime, these are not passed on to the child.
+When `uzbl` forks a new instance (eg "open in new window") it will use the same command line arguments (eg the same `--config <file>`), except `--uri` and `--name`. If you made changes to the configuration at runtime, these are not passed on to the child.
 
 #### Uzbl-browser
 
@@ -79,9 +78,9 @@ When uzbl forks a new instance (eg "open in new window") it will use the same co
 
 ### COMMAND SYNTAX
 
-Uzbl will read commands via standard input, named fifo pipe (if `fifo_dir` is set) and IPC socket (when `socket_dir` is set). For convenience, uzbl can also be instructed to read commands from a file on startup by using the `--config` option. Indeed, the config file is nothing more than a list of commands.
+Uzbl will read commands via standard input, named FIFO pipe (if `fifo_dir` is set) and Unix socket (when `socket_dir` is set). For convenience, `uzbl` can also be instructed to read commands from a file on startup by using the `--config` option. Indeed, the config file is nothing more than a list of commands.
 
-Each command starts with the name of the command or an uzbl variable that expands to it. A command is terminated by a newline. Empty lines and lines that start with the hash sign are ignored by the parser. Command names are always written in lowercase.
+Each command starts with the name of a command or a `uzbl` variable that expands to it. A command is terminated by a newline. Empty lines and lines that start with the hash sign are ignored by the parser. Command names are always written in lowercase.
 
 The following commands are recognized:
 
@@ -104,24 +103,26 @@ The following commands are recognized:
 * `zoom_out`
 * `uri <address>`
 * `js <body>`
-  - execute the javascript in `<body>`
-  - remember that the commands must not contain line breaks
+  - Execute the javascript in `<body>`.
+  - Remember that the commands must not contain line breaks.
 * `script <file>`
-  - execute the javascript in `<file>`
+  - Execute the javascript in `<file>`.
 * `toggle_status`
 * `spawn <executable> <additional args>` TODO explain path-alike expansion
-  - runs a command; see EXTERNAL SCRIPTS for details
-  - PATH is searched so giving the full path to commands is not necessary
-  - note that the arguments as specified in "EXTERNAL SCRIPTS" are appended at the end, so the argument numbers will be higher.
+  - Runs a command; see EXTERNAL SCRIPTS for details.
+  - `$PATH` is searched, so giving the full path to commands is not necessary.
+  - Note that the arguments as specified in "EXTERNAL SCRIPTS" are appended at the end, so the argument numbers will be higher.
 * `sh <command>`
-  - runs a shell command by expanding `%s` in the `shell_cmd` variable with the specified command; primarily useful as a shortcut for `spawn sh -c <body>`
-  - note that the arguments as specified in "EXTERNAL SCRIPTS" are appended at the end, so the argument numbers will be higher.
+  - Runs a shell command by expanding `%s` in the `shell_cmd` variable with the specified command; primarily useful as a shortcut for `spawn sh -c <command>`
+  - Note that the arguments as specified in "EXTERNAL SCRIPTS" are appended at the end, so the argument numbers will be higher.
 * `sync_spawn <executable> <additional args>`
 * `sync_sh <command>`
-  - these are synchronous variants of `spawn` and `sh`, which means uzbl will wait for them to return
-  - you should only need to use these manually if you want to use a chain command in a handler that wants output from the command it runs
-* `talk_to_socket <socketfile> <tokens/command>`
-  - lets uzbl talk to a socketfile
+  - These are synchronous variants of `spawn` and `sh`, which means `uzbl` will wait for them to return.
+  - You should only need to use these manually if you want to use a chain command in a handler that wants output from the command it runs.
+* `talk_to_socket <socketfile> <tokens>`
+  - Send a message to `<socketfile>` and wait for a response. `<tokens>` are concatenated and separated by ASCII NUL bytes.
+  - Expects the socket type to be `SOCK_SEQPACKET` (see connect(2) ).
+  - Waits for 500ms for a response.
 * `exit`
 * `search <string>`
 * `search_reverse <string>`