Eliminate some eol-spacing, eliminate some gcc warnings (with -Wc++-compat)

1 files changed, 3 insertions, 3 deletions

diff --git a/doc/clock.n b/doc/clock.n
index 4440c4d..7f05127 100644
--- a/doc/clock.n
+++ b/doc/clock.n
@@ -581,7 +581,7 @@ The epoch time of 1 January 1970 corresponds to Astronomical JDN 2440588.
 \fB%Es\fR
 This affects similar to \fB%s\fR, but in opposition to \fB%s\fR it parses
 or formats local seconds (not the posix seconds).
-Because \fB%s\fR has the same precedence as \fB%s\fR (uniquely determines 
+Because \fB%s\fR has the same precedence as \fB%s\fR (uniquely determines
 a point in time), it overrides all other input formats.
 .TP
 \fB%Ex\fR
@@ -778,7 +778,7 @@ week number \fB%V\fR; programs should use \fB%G\fR for that purpose.
 On output, produces the current time zone, expressed in hours and
 minutes east (+hhmm) or west (\-hhmm) of Greenwich. On input, accepts a
 time zone specifier (see \fBTIME ZONES\fR below) that will be used to
-determine the time zone (this token is optionally applicable on input, 
+determine the time zone (this token is optionally applicable on input,
 so the value is not mandatory and can be missing in input).
 .TP
 \fB%Z\fR
@@ -994,7 +994,7 @@ precision of type of the token.
 In example below the second date-string contains "next January", therefore
 it results in next year but in January. And third date-string besides "January"
 contains also additionally "Fri", so it results in the nearest Friday.
-Thus both win before "385 days" resp. make it more precise, because of higher 
+Thus both win before "385 days" resp. make it more precise, because of higher
 precision of this token types.
 .CS
 % clock format [clock scan "5 years 18 months 385 days" -base 0 -gmt 1] -gmt 1