+Elpher has a very simple link bookmarking system involving the
+following commands:
+
+@table @asis
+@keycmd{@key{a}, elpher-bookmark-link}
+Add a bookmark for the link at point. The minibuffer will prompt for
+a name for the bookmark, which defaults to the display string.
+
+@keycmd{@key{A}, elpher-bookmark-current}
+Add a bookmark for the current page. The minibuffer will prompt for
+a name for the bookmark, defaulting to the display string associated
+with the link that was followed to reach the current page.
+
+@keycmd{@key{x}, elpher-unbookmark-link}
+Immediately remove the bookmark (if one exists) to the link at point.
+
+@keycmd{@key{X}, elpher-unbookmark-current}
+Immediately remove the bookmark (if one exists) to the current page.
+
+@keycmd{@key{B}, elpher-bookmarks}
+Open a page displaying all current bookmarks. Note that this bookmark
+page is added to the history just as if you had opened it using a link.
+Thus to return to the previous page, use @kbd{u}. This also means
+that you can peruse the various bookmarks by visiting them in turn,
+using @kbd{u} to return to the bookmark page (where the position of point
+is cached), then moving to another bookmarked link and so on.
+@end table
+
+Bookmarks are stored as a s-exp in the file @file{elpher-bookmarks}
+in the user emacs directory (usually @file{~/.emacs.d/}).
+Any command which modifies the list of bookmarks immediately updates
+this file.
+
+@node Gopher character encodings, Encrypted gopher connections, Bookmarks, Top
+@chapter Gopher character encodings
+
+Responses Elpher retrieves from servers are initially read as pure
+binary data. When the data is intended to be interpreted as textual (as
+determined by the type parameter of the gopher menu item or the gopher
+URL), this data needs to be @emph{decoded} into a sequence of
+characters. To do this properly requires knowledge of the encoding
+system used by whoever authored the document.
+
+Unfortunately gopher lacks a systematic way of acquiring this necessary
+information. Thus, the details of the coding system must be either inferred from the binary data,
+or must be specified by the user.
+
+By default, Elpher applies Emacs' built-in character encoding detection
+system to the full (undecoded) response data and uses this to attempt to
+convert it into a character string.
+(See @pxref{Recognize coding, Recognizing coding systems, ,emacs}.) While
+this approach can be okay, it is important to realize that its inference
+algorithm is extremely primitive and depends heavily on assumptions based
+on the language settings of your emacs system.
+
+The alternative is to explicitly set the coding system used for decoding
+using the following command:
+
+@table @asis
+@keycmd{@key{S},elpher-set-coding-system}
+Causes a elpher to prompt for a coding system to use for decoding
+future gopher text. The @key{TAB} key can be used at this prompt to display a
+list of alternatives (which is extensive) and to auto-complete. An empty
+response will cause Elpher to return to its default auto-detection
+behaviour.
+@end table
+
+Note that changing the coding system only affects newly loaded text.
+Thus, if text has already been decoded using an incorrect system, you
+will need to select the correct coding and then reload the text using
+@key{R}.
+
+
+@node Encrypted gopher connections, Gemini support, Gopher character encodings, Top
+@chapter Encrypted gopher connections
+
+While RFC 1436 does not broach the topic of encryption at all, several
+modern gopher servers can serve content over encrypted connections,
+and a common choice for this is TLS.
+
+Elpher can retrieve selectors using Emacs' built-in TLS support which
+uses the GnuTLS library. (It is possible to build emacs without
+GnuTLS, in which case encryption is not supported.)
+
+To retrieve documents using TLS, Elpher's TLS mode must be enabled.
+This can be directly toggled using @key{T}, but note that just as with
+the character encoding, changing this mode only affects subsequent
+connections.
+
+Alternatively, TLS mode is @emph{automatically} enabled whenever
+gopher URLs starting with @code{gophers://} are followed.
+
+The mode is sticky, so it remains active until switched off.
+It can also be automatically switched off when a TLS connection fails.
+In this case Elpher will prompt for your confirmation to ensure that
+you can't accidentally make a non-TLS connection.
+
+@node Gemini support, Finger support, Encrypted gopher connections, Top
+@chapter Gemini support
+
+@uref{gopher://gemini.circumlunar.space, Gemini}
+is a new protocol being devloped by several members of
+gopherspace. It aims to solve some of the long-standing technical
+issues associated with gopher as a protocol, while keeping the major benifits.
+For instance, it _requires_ encrypted connections, it does away with
+the selector type, and allows servers to explicitly specify the
+character coding scheme used for text documents.
+
+The latest versions of Elpher aim to provide seemless navigation between
+gemini and gopher documents. Basically you should be able to open,
+bookmark, download and otherwise interact with gemini pages in exactly
+the same way as you do with other non-gemini pages. The only major
+difference from your perspective as a user is that you should no longer
+have to worry about manually toggling TLS on or off (for gemini it's
+always on), and you should never have to manually set a character coding
+scheme.
+
+The gemini protocol specification recommends a Trust on First Use (TOFU)
+behaviour when validating gemini server TLS certificates. This is
+because many gemini servers rely on self-signed certificates rather
+than certificates signed by a CA. Sadly however, this TOFU behaviour is
+far from straight-forward to configure using Emacs' existing Network
+Security Manager. For this reason, elpher defaults to performing no
+certificate verification by default. This behaviour can be easily
+customized by setting the @code{elpher-gemini-TLS-cert-checks}
+customization variable to non-nil.
+
+Like gopher, the gemini specification concerns both the protocol
+ a simple text document format (mimetype text/gemini) which is
+like a mixture between gophermap files and markdown-formatted files but
+simpler than both. Elpher renders gemini responses which are provided
+in this format in line with the rules in the spec. This includes
+wrapping long lines at word boundaries. The specific column at which
+this text is wrapped is defined by the customization variable
+@code{elpher-gemini-max-fill-width}, which is set to 80 columns by
+default. (This is slightly wider than Emacs' default fill width of 70
+columns due to the fact that there are a significant amount of older
+gemini which, against the advice of the current spec, hard wraps at <80
+columns. The larger default allows this to still look okay, while
+still keeping content without hard wraps looking pleasant.)
+
+The text/gemini format also posesses a section header syntax similar to
+markdown. Elpher allows different header levels to be drawn with
+different, customizable, faces. By default, on graphically-capable
+emacs systems, these faces are given different heights to distinguish
+amongst levels. On terminal systems, the level is indicated by the
+number of preceeding # symbols.
+
+I should emphasize however that, while it is definitely functional,
+Elpher's gemini support is still experimental, and various aspects will
+change as the protocol develops further. Additionally, the use of
+client TLS certicificates is still not yet supported.
+
+@node Finger support, Customization, Gemini support, Top
+@chapter Finger support
+
+Incidentally, Elpher has native support for querying finger servers.
+Of course, one could argue that this functionality is more easily
+provided by one's local telnet client. However finger URLs do appear
+on occasion in gopherspace, and it's nice to be able to open them
+in place.
+
+Elpher interprets @code{finger://} URLs as follows:
+
+@itemize
+
+@item
+The host is determined by the host name portion of the URL.
+
+@item
+In the case that the @emph{file name} portion of the URL is non-empty (besides
+the leading slash), this is interpreted as the user to finger.
+
+@item
+Otherwise, the @emph{user} portion of the URL is interpreted as the user to finger.