Multiple small changes/fixed typos to docs/error messages (#623)

readthedocs/extra/basic/entities.rst

@@ -43,14 +43,15 @@ you're able to just do this:
         my_channel = client.get_entity(PeerChannel(some_id))
 
 
-All methods in the :ref:`telegram-client` call ``.get_input_entity()`` to
-further save you from the hassle of doing so manually, so doing things like
-``client.send_message('lonami', 'hi!')`` is possible.
+All methods in the :ref:`telegram-client` call ``.get_input_entity()`` prior
+to sending the requst to save you from the hassle of doing so manually.
+That way, convenience calls such as ``client.send_message('lonami', 'hi!')``
+become possible.
 
-Every entity the library "sees" (in any response to any call) will by
-default be cached in the ``.session`` file, to avoid performing
-unnecessary API calls. If the entity cannot be found, some calls
-like ``ResolveUsernameRequest`` or ``GetContactsRequest`` may be
+Every entity the library encounters (in any response to any call) will by
+default be cached in the ``.session`` file (an SQLite database), to avoid
+performing unnecessary API calls. If the entity cannot be found, additonal
+calls like ``ResolveUsernameRequest`` or ``GetContactsRequest`` may be
 made to obtain the required information.
 
 
@@ -61,16 +62,18 @@ Entities vs. Input Entities
 
     Don't worry if you don't understand this section, just remember some
     of the details listed here are important. When you're calling a method,
-    don't call ``.get_entity()`` before, just use the username or phone,
+    don't call ``.get_entity()`` beforehand, just use the username or phone,
     or the entity retrieved by other means like ``.get_dialogs()``.
 
 
-To save bandwidth, the API also makes use of their "input" versions.
-The input version of an entity (e.g. ``InputPeerUser``, ``InputChat``,
-etc.) only contains the minimum required information that's required
-for Telegram to be able to identify who you're referring to: their ID
-and hash. This ID/hash pair is unique per user, so if you use the pair
-given by another user **or bot** it will **not** work.
+On top of the normal types, the API also make use of what they call their
+``Input*`` versions of objects. The input version of an entity (e.g.
+``InputPeerUser``, ``InputChat``, etc.) only contains the minimum
+information that's required from Telegram to be able to identify
+who you're referring to: a ``Peer``'s **ID** and **hash**.
+
+This ID/hash pair is unique per user, so if you use the pair given by another
+user **or bot** it will **not** work.
 
 To save *even more* bandwidth, the API also makes use of the ``Peer``
 versions, which just have an ID. This serves to identify them, but

readthedocs/extra/basic/installation.rst

@@ -65,9 +65,10 @@ To generate the `method documentation`__, ``cd docs`` and then
 Optional dependencies
 *********************
 
-If ``libssl`` is available on your system, it will be used wherever encryption
-is needed, but otherwise it will fall back to pure Python implementation so it
-will also work without it.
+If the `cryptg`__ is installed, you might notice a speed-up in the download
+and upload speed, since these are the most cryptographic-heavy part of the
+library and said module is a C extension. Otherwise, the ``pyaes`` fallback
+will be used.
 
 
 __ https://github.com/ricmoo/pyaes
@@ -75,3 +76,4 @@ __ https://pypi.python.org/pypi/pyaes
 __ https://github.com/sybrenstuvel/python-rsa
 __ https://pypi.python.org/pypi/rsa/3.4.2
 __ https://lonamiwebs.github.io/Telethon
+__ https://github.com/Lonami/cryptg

readthedocs/extra/basic/working-with-updates.rst

@@ -10,6 +10,16 @@ over what Telegram calls `updates`__, and are meant to ease simple and common
 usage when dealing with them, since there are many updates. Let's dive in!
 
 
+.. note::
+
+    The library logs by default no output, and any exception that occurs
+    inside your handlers will be "hidden" from you to prevent the thread
+    from terminating (so it can still deliver events). You should enable
+    logging (``import logging; logging.basicConfig(level=logging.ERROR)``)
+    when working with events, at least the error level, to see if this is
+    happening so you can debug the error.
+
+
 .. contents::