man page: typos and grammar

doc/riverguile.1

@@ -18,7 +18,7 @@ Scripting layer for the
 Wayland server.
 Allows the user to send commands to the Wayland server (probably river) and
 install handlers for events from a scheme script.
-The sheme implementation is provided by
+The scheme implementation is provided by
 .BR guile (1).
 .P
 The canonical way to use riverguile is as an interpreter for the river init
@@ -32,14 +32,14 @@ To do so place the following expression at the very top of your init script:
 .EE
 .RE
 .P
-Do not leave out the second line, as the octothorpe plus exlamation-mark
+Do not leave out the second line, as the octothorpe plus exclamation-mark
 combination indicates a multi-line comment in scheme.
 Do not forget to mark your init script as executable.
 Your custom scheme code to configure the river session may follow after these
 two lines.
 .P
 By default, riverguile will exit after the script has been loaded.
-However if certain handlers are installed it will run continously to provide
+However if certain handlers are installed it will run continuously to provide
 that functionality.
 .
 .
@@ -89,7 +89,7 @@ Riverguile exposes the special procedure
 event handlers.
 The parameter \fIkey\fR is a symbol indicating for which event to install
 the procedure \fIproc\fR.
-The following keys are currently evailable:
+The following keys are currently available:
 .
 .P
 \fBlayout-demand\fR
@@ -99,7 +99,7 @@ Installing a handler for this key allows the user to provide window layouts.
 All limitations of the river-layout-v3 protocol apply.
 The server will trigger this event when a new layout is required ("demanded").
 .P
-Installing a layout-demand handler will cause riverguile to run continously.
+Installing a layout-demand handler will cause riverguile to run continuously.
 .P
 The handler procedure must accept five required arguments, which are, in order:
 The amount of views in the layout (integer), the available width (integer), the
@@ -136,17 +136,24 @@ windows use all available space:
 \fBuser-command\fR
 .P
 .RS
-User commands are intended to send commands to layout generators, allowing the
-user to update parameters of the layout live.
+User commands are intended to allowing the user to update parameters of the
+layout live.
+The user sends a command - a string - to the server, which relays is to the
+layout generator.
 Of course, nothing is stopping you from (ab-)using this event to trigger
-arbitrary scheme code on keypresses or on outside events, or from simply not
+arbitrary scheme code on key presses or on outside events, or from simply not
 using it at all.
-After a user-command has been received, the server can will trigger a
-layout-demand if there are visible windows.
+Please see
+.BR riverctl (1)
+regarding how to send user commands and how to configure the server to send them
+on key presses (note that usage of the riverctl executable maps one-to-one to
+the usage of the riverguile procedure of the same name).
+After a user-command has been received, the server will trigger a layout-demand
+if there are visible windows.
 .P
-Installing a user-command handler will \fInot\fR cause riverguile to run continously.
+Installing a user-command handler will \fInot\fR cause riverguile to run continuously.
 This event is an extension to the layout-demand event and as such it is invalid
-to install a user-command handler without also installing a layout-demant
+to install a user-command handler without also installing a layout-demand
 handler.
 .P
 The handler procedure must accept three arguments, which are, in order:
@@ -174,7 +181,7 @@ Note that this is not necessarily good practice, but serves as a decent example.
 A handler installed for this key will be triggered after the system has been
 idle for \fIX\fR seconds and once more once the system is no longer idle.
 .P
-Installing a layout-demand handler will cause riverguile to run continously.
+Installing an idle handler will cause riverguile to run continuously.
 Multiple idle handlers can be installed.
 .P
 Idle state is server policy and may depend on a multitude of factors, but
@@ -187,23 +194,23 @@ This symbol is either \fBidle\fR, indicating the system has been idle for the
 configured amount of time, or \fBresume\fR, indicating that the system is no
 longer idle.
 .P
-Here is an example which will dim the screen after two minutes of inactiviy
-and lock it after fice:
+Here is an example which will dim the screen after two minutes of inactivity
+and lock it after five:
 .P
 .RS
 .EX
 (\fBinstall-handler\fR 'idle:120
   (\fBlambda\fR (event)
-    (\fBcond\fR ((\fBeq?\fR event 'idle) (\fBsystem\fR "light -S 20"))
-          ((\fBeq?\fR event 'resume) (\fBsystem\fR "light -S 100")))))
+    (\fBcond\fR ((\fBeq?\fR event 'idle) (riverctl "spawn" "light -S 20"))
+          ((\fBeq?\fR event 'resume) (riverctl "spawn" "light -S 100")))))
 
 (\fBinstall-handler\fR 'idle:300
   (\fBlambda\fR (event)
-    (if (\fBeq?\fR event 'idle) (\fBsystem\fR "swaylock &"))))
+    (if (\fBeq?\fR event 'idle) (riverctl "spawn" "swaylock"))))
 .EE
 .RE
 .P
-Note: All idle events relate to the first advetised seat.
+Note: All idle events relate to the first advertised seat.
 As of now, river only supports a single seat anyway.
 .RE
 .
@@ -221,7 +228,7 @@ Here is an example which adds a message to the system log on exit:
 .EX
 (\fBinstall-handler\fR 'exit
   (\fBlambda\fR ()
-    (\fBsystem\fR "logger 'goodbye from riverguile'")))
+    (riverctl "spawn" "logger 'goodbye from riverguile'")))
 .EE
 .RE
 .RE