Clean-up docs and merge some imports

readthedocs/extra/advanced-usage/accessing-the-full-api.rst

@@ -11,10 +11,10 @@ Accessing the Full API
     reason not to, like a method not existing or you wanting more control.
 
 
-The ``TelegramClient`` doesn't offer a method for every single request
-the Telegram API supports. However, it's very simple to *call* or *invoke*
-any request. Whenever you need something, don't forget to `check the
-documentation`__ and look for the `method you need`__. There you can go
+The `telethon.telegram_client.TelegramClient` doesn't offer a method for every
+single request the Telegram API supports. However, it's very simple to *call*
+or *invoke* any request. Whenever you need something, don't forget to `check
+the documentation`__ and look for the `method you need`__. There you can go
 through a sorted list of everything you can do.
 
 
@@ -30,9 +30,9 @@ You should also refer to the documentation to see what the objects
 (constructors) Telegram returns look like. Every constructor inherits
 from a common type, and that's the reason for this distinction.
 
-Say ``client.send_message()`` didn't exist, we could use the `search`__
-to look for "message". There we would find :tl:`SendMessageRequest`,
-which we can work with.
+Say `telethon.telegram_client.TelegramClient.send_message` didn't exist,
+we could use the `search`__ to look for "message". There we would find
+:tl:`SendMessageRequest`, which we can work with.
 
 Every request is a Python class, and has the parameters needed for you
 to invoke it. You can also call ``help(request)`` for information on
@@ -63,7 +63,7 @@ construct one, for instance:
 
         peer = InputPeerUser(user_id, user_hash)
 
-Or we call ``.get_input_entity()``:
+Or we call `telethon.telegram_client.TelegramClient.get_input_entity()`:
 
     .. code-block:: python
 
@@ -74,7 +74,7 @@ When you're going to invoke an API method, most require you to pass an
 ``.get_input_entity()`` is more straightforward (and often
 immediate, if you've seen the user before, know their ID, etc.).
 If you also need to have information about the whole user, use
-``.get_entity()`` instead:
+`telethon.telegram_client.TelegramClient.get_entity()` instead:
 
     .. code-block:: python
 
@@ -83,7 +83,7 @@ If you also need to have information about the whole user, use
 In the later case, when you use the entity, the library will cast it to
 its "input" version for you. If you already have the complete user and
 want to cache its input version so the library doesn't have to do this
-every time its used, simply call ``.get_input_peer``:
+every time its used, simply call `telethon.utils.get_input_peer`:
 
     .. code-block:: python
 

readthedocs/extra/advanced-usage/sessions.rst

@@ -7,7 +7,7 @@ Session Files
 The first parameter you pass to the constructor of the ``TelegramClient`` is
 the ``session``, and defaults to be the session name (or full path). That is,
 if you create a ``TelegramClient('anon')`` instance and connect, an
-``anon.session`` file will be created on the working directory.
+``anon.session`` file will be created in the working directory.
 
 Note that if you pass a string it will be a file in the current working
 directory, although you can also pass absolute paths.

readthedocs/extra/advanced-usage/update-modes.rst

@@ -44,7 +44,7 @@ That's it! This is the old way to listen for raw updates, with no further
 processing. If this feels annoying for you, remember that you can always
 use :ref:`working-with-updates` but maybe use this for some other cases.
 
-Now let's do something more interesting. Every time an user talks to use,
+Now let's do something more interesting. Every time an user talks to us,
 let's reply to them with the same text reversed:
 
     .. code-block:: python