fixing two typos; incomplete error message; exit status

Benno Schulenberg <[email protected]> Wed, 23 Oct 2019 11:34:11 +0200
Newsgroups gmane.comp.gnu.aspell.devel
Message-ID <[email protected]>
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--fdnfz38AkGARsrV7IyBc311iZU0F4gSY7
Content-Type: multipart/mixed; boundary="M9VEZhWmjXm7JXiphjUFlINPkNrL58o9Z";
 protected-headers="v1"
From: Benno Schulenberg <[email protected]>
To: [email protected]
Message-ID: <[email protected]>
Subject: fixing two typos; incomplete error message; exit status

--M9VEZhWmjXm7JXiphjUFlINPkNrL58o9Z
Content-Type: multipart/mixed;
 boundary="------------ADD52ECCCF20E5C3B9CE9E09"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------ADD52ECCCF20E5C3B9CE9E09
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hello Kevin,

Looking through the documentation of 0.60.8 for some info about
the exit status of aspell, I came across a typo ("termianted")
in the README file.  Then I spell-checked the whole thing and
found another ("implemenation").  Attached patch fixes those.

Then something I've wanted to report since a long time: most
tools allow one to bundle the short options, but aspell doesn't.
When one tries to run 'aspell -xc somefile' it not only fails,
it also says:

  Error:  does not take any parameters.

Something appears to be missing ("-x"?) from the message.

So, it would be good if the manual said that short options
may not be concatenated.

And it would be nice if the manual said something about the
exit status of aspell.  That it is zero when no error occurred.
Whether spelling corrections were made or not cannot be seen
in the exit status.

(On http://aspell.net/ there's a typo too: s/slower/slowly/.)

Benno

--------------ADD52ECCCF20E5C3B9CE9E09
Content-Type: text/x-patch;
 name="0001-docs-fix-two-typos.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0001-docs-fix-two-typos.patch"

=46rom 4c5f97b20d22299e9c37c8c07f16a792f86d2ac8 Mon Sep 17 00:00:00 2001
From: Benno Schulenberg <[email protected]>
Date: Wed, 23 Oct 2019 11:02:18 +0200
Subject: [PATCH] docs: fix two typos

---
 manual/readme.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/manual/readme.texi b/manual/readme.texi
index fdd4eb2..6dd0e34 100644
--- a/manual/readme.texi
+++ b/manual/readme.texi
@@ -157,7 +157,7 @@ Error: The file ``@var{some-file}'' is not in the pro=
per format. Incompatible ha
=20
 To prevent a potentially unbounded buffer over-read, Aspell no longer
 supports null-terminated UCS-2 and UCS-4 encoded strings with the
-original C API.  Null-termianted 8-bit or UTF-8 encoded strings are
+original C API.  Null-terminated 8-bit or UTF-8 encoded strings are
 still supported, as are UCS-2 and UCS-4 encoded strings when the
 length is passed in.
=20
@@ -184,7 +184,7 @@ could result in an unbounded buffer over-read.
 If it is necessary to preserve binary compatibility with older
 versions of Aspell, the easiest thing would be to determine the length
 of the UCS-2/4 string---in bytes---and pass that in.  Due to an
-implemenation detail, existing API functions can be made to work with
+implementation detail, existing API functions can be made to work with
 null-terminated UCS-2/4 strings safely by passing in either @code{-2}
 or @code{-4} (corresponding to the width of the character type) as the
 size.  Doing so, however, will cause a buffer over-read for unpatched
--=20
2.23.0


--------------ADD52ECCCF20E5C3B9CE9E09--

--M9VEZhWmjXm7JXiphjUFlINPkNrL58o9Z--

--fdnfz38AkGARsrV7IyBc311iZU0F4gSY7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEv9AJBh5TUFKtDfIVDSjU0qCs6IQFAl2wHpsACgkQDSjU0qCs
6ITdBA//TMsY3VNQAAN3+BroEbQlpYn8PmjOQpDhPeIQuzFI/AyljM+xGXH/SD4q
3tyiLBmB6zq6UXbDFKhECWbUhFk1PfPD23j0loYvAskPhoYDKO81AEojZcSxdDSs
0eTMUKpFn2uskjw/mh7yYAk0ulBqc/WYFlhhRGavIYMc/H85kxkyFd+LZTEnH5Pe
Ez//gakw2U3mlhO1+EKzBbuMTarrdA7uEdix4zhcfGIjiwPfKRk5b6PajH2L+D71
Q/ZTwIIVeLZOhPy3aZlcO7O72B3wSEQjqMPd4Vt+DiAwBmj15Y2q3QrKdBaowhd3
9Porq1KzyBcDPj2e/sUNIbl5B5qHdUr9z8k/bIWXyL1Pz1YIuXvewmsu6PXFztmR
CfAHMSdPPkLbna526U1PV72bMJdlzyefAg/NArudFb880c40mAh4lmAjldr9wBUp
IWPtsAy2AmRXq+m7FYEHkwOaPH6dX1CDRKlCgEUvOGj6SZl3buQ+sm3o8QMKEvhL
R/NFqLM1Kh2ZSr6EgcNWlks6X24AwjoYaWfQQ6IW2GQi6ehZHEmWtWbFsc7ID+95
g0eauaL1CFAwKwstCe5NMl09KaMiN5zGwqoTH9gIwirv0Eyuk2V+J/UCeX6wxIbG
3glPpH9Pk0ECW1TKxzftZZTj/b5Qa1YUwbUt0L+lZnfmuKBgdiA=
=fgZN
-----END PGP SIGNATURE-----

--fdnfz38AkGARsrV7IyBc311iZU0F4gSY7--