Update docs

docs/source/topics/advanced-usage.rst

@@ -1,8 +1,9 @@
 Advanced Usage
 ==============
 
-Pyrogram's API, which consists of well documented convenience methods_ and facade types_, exists to provide a much
-easier interface to the undocumented and often confusing Telegram API.
+Pyrogram's API, which consists of well documented convenience :doc:`methods <../api/methods>` and facade
+:doc:`types <../api/types>`, exists to provide a much easier interface to the undocumented and often confusing Telegram
+API.
 
 In this section, you'll be shown the alternative way of communicating with Telegram using Pyrogram: the main "raw"
 Telegram API with its functions and types.
@@ -11,7 +12,7 @@ Telegram Raw API
 ----------------
 
 If you can't find a high-level method for your needs or if you want complete, low-level access to the whole
-Telegram API, you have to use the raw :mod:`functions <pyrogram.api.functions>` and :mod:`types <pyrogram.api.types>`.
+Telegram API, you have to use the raw :mod:`~pyrogram.api.functions` and :mod:`~pyrogram.api.types`.
 
 As already hinted, raw functions and types can be really confusing, mainly because people don't realize soon enough they
 accept *only* the right types and that all required parameters must be filled in. This section will therefore explain
@@ -21,24 +22,25 @@ some pitfalls to take into consideration when working with the raw API.
 
     Every available high-level methods in Pyrogram is built on top of these raw functions.
 
-    Nothing stops you from using the raw functions only, but they are rather complex and `plenty of them`_ are already
-    re-implemented by providing a much simpler and cleaner interface which is very similar to the Bot API (yet much more
-    powerful).
+    Nothing stops you from using the raw functions only, but they are rather complex and
+    :doc:`plenty of them <../api/methods>` are already re-implemented by providing a much simpler and cleaner interface
+    which is very similar to the Bot API (yet much more powerful).
 
     If you think a raw function should be wrapped and added as a high-level method, feel free to ask in our Community_!
 
 Invoking Functions
 ^^^^^^^^^^^^^^^^^^
 
-Unlike the methods_ found in Pyrogram's API, which can be called in the usual simple way, functions to be invoked from
-the raw Telegram API have a different way of usage and are more complex.
+Unlike the :doc:`methods <../api/methods>` found in Pyrogram's API, which can be called in the usual simple way,
+functions to be invoked from the raw Telegram API have a different way of usage and are more complex.
 
-First of all, both `raw functions`_ and `raw types`_ live in their respective packages (and sub-packages):
-``pyrogram.api.functions``, ``pyrogram.api.types``. They all exist as Python classes, meaning you need to create an
-instance of each every time you need them and fill them in with the correct values using named arguments.
+First of all, both :doc:`raw functions <../telegram/functions/index>` and :doc:`raw types <../telegram/types/index>` live in their
+respective packages (and sub-packages): ``pyrogram.api.functions``, ``pyrogram.api.types``. They all exist as Python
+classes, meaning you need to create an instance of each every time you need them and fill them in with the correct
+values using named arguments.
 
-Next, to actually invoke the raw function you have to use the :meth:`send() <pyrogram.Client.send>` method provided by
-the Client class and pass the function object you created.
+Next, to actually invoke the raw function you have to use the :meth:`~pyrogram.Client.send` method provided by the
+Client class and pass the function object you created.
 
 Here's some examples:
 
@@ -101,12 +103,12 @@ sending messages with IDs only thanks to cached access hashes.
 There are three different InputPeer types, one for each kind of Telegram entity.
 Whenever an InputPeer is needed you must pass one of these:
 
-    - :obj:`InputPeerUser <../telegram/types/InputPeerUser>` - Users
-    - :obj:`InputPeerChat <../telegram/types/InputPeerChat>` -  Basic Chats
-    - :obj:`InputPeerChannel <../telegram/types/InputPeerChannel>` - Either Channels or Supergroups
+    - :class:`~pyrogram.api.types.InputPeerUser` - Users
+    - :class:`~pyrogram.api.types.InputPeerChat` -  Basic Chats
+    - :class:`~pyrogram.api.types.InputPeerChannel` - Either Channels or Supergroups
 
 But you don't necessarily have to manually instantiate each object because, luckily for you, Pyrogram already provides
-:meth:`resolve_peer() <pyrogram.Client.resolve_peer>` as a convenience utility method that returns the correct InputPeer
+:meth:`~pyrogram.Client.resolve_peer` as a convenience utility method that returns the correct InputPeer
 by accepting a peer ID only.
 
 Another thing to take into consideration about chat IDs is the way they are represented: they are all integers and
@@ -125,9 +127,4 @@ For example, given the ID *123456789*, here's how Pyrogram can tell entities apa
 So, every time you take a raw ID, make sure to translate it into the correct ID when you want to use it with an
 high-level method.
 
-.. _methods: ../api/methods
-.. _types: ../api/types
-.. _plenty of them: ../api/methods
-.. _raw functions: ../telegram/functions
-.. _raw types: ../telegram/types
 .. _Community: https://t.me/Pyrogram

docs/source/topics/auto-auth.rst

@@ -3,7 +3,7 @@ Auto Authorization
 
 Manually writing phone number, phone code and password on the terminal every time you want to login can be tedious.
 Pyrogram is able to automate both **Log In** and **Sign Up** processes, all you need to do is pass the relevant
-parameters when creating a new :class:`Client <pyrogram.Client>`.
+parameters when creating a new :class:`~pyrogram.Client`.
 
 .. note:: If you omit any of the optional parameter required for the authorization, Pyrogram will ask you to
    manually write it. For instance, if you don't want to set a ``last_name`` when creating a new account you

docs/source/topics/bots-interaction.rst

@@ -7,8 +7,7 @@ Inline Bots
 -----------
 
 -   If a bot accepts inline queries, you can call it by using
-    :meth:`get_inline_bot_results() <pyrogram.Client.get_inline_bot_results>` to get the list of its inline results
-    for a query:
+    :meth:`~pyrogram.Client.get_inline_bot_results` to get the list of its inline results for a query:
 
     .. code-block:: python
 
@@ -24,7 +23,7 @@ Inline Bots
         results list.
 
 -   After you retrieved the bot results, you can use
-    :meth:`send_inline_bot_result() <pyrogram.Client.send_inline_bot_result>` to send a chosen result to any chat:
+    :meth:`~pyrogram.Client.send_inline_bot_result` to send a chosen result to any chat:
 
     .. code-block:: python
 

docs/source/topics/filters.rst

@@ -4,7 +4,7 @@ Using Filters
 So far we've seen how to register a callback function that executes every time a specific update comes from the server,
 but there's much more than that to come.
 
-Here we'll discuss about :class:`Filters <pyrogram.Filters>`. Filters enable a fine-grain control over what kind of
+Here we'll discuss about :class:`~pyrogram.Filters`. Filters enable a fine-grain control over what kind of
 updates are allowed or not to be passed in your callback functions, based on their inner details.
 
 Single Filters
@@ -12,7 +12,7 @@ Single Filters
 
 Let's start right away with a simple example:
 
--   This example will show you how to **only** handle messages containing an :obj:`Audio <pyrogram.Audio>` object and
+-   This example will show you how to **only** handle messages containing an :class:`~pyrogram.Audio` object and
     ignore any other message. Filters are passed as the first argument of the decorator:
 
     .. code-block:: python
@@ -69,7 +69,7 @@ Here are some examples:
 Advanced Filters
 ----------------
 
-Some filters, like :meth:`command() <pyrogram.Filters.command>` or :meth:`regex() <pyrogram.Filters.regex>`
+Some filters, like :meth:`~pyrogram.Filters.command` or :meth:`~pyrogram.Filters.regex`
 can also accept arguments:
 
 -   Message is either a */start* or */help* **command**.
@@ -109,18 +109,18 @@ More handlers using different filters can also live together.
 Custom Filters
 --------------
 
-Pyrogram already provides lots of built-in :class:`Filters <pyrogram.Filters>` to work with, but in case you can't find
+Pyrogram already provides lots of built-in :class:`~pyrogram.Filters` to work with, but in case you can't find
 a specific one for your needs or want to build a custom filter by yourself (to be used in a different kind of handler,
-for example) you can use :meth:`Filters.create() <pyrogram.Filters.create>`.
+for example) you can use :meth:`~pyrogram.Filters.create`.
 
 .. note::
-    At the moment, the built-in filters are intended to be used with the :obj:`MessageHandler <pyrogram.MessageHandler>`
-    only.
+
+    At the moment, the built-in filters are intended to be used with the :class:`~pyrogram.MessageHandler` only.
 
 An example to demonstrate how custom filters work is to show how to create and use one for the
-:obj:`CallbackQueryHandler <pyrogram.CallbackQueryHandler>`. Note that callback queries updates are only received by
-bots; create and `authorize your bot <../start/Setup.html#bot-authorization>`_, then send a message with an inline
-keyboard to yourself. This allows you to test your filter by pressing the inline button:
+:class:`~pyrogram.CallbackQueryHandler`. Note that callback queries updates are only received by bots; create and
+:doc:`authorize your bot <../start/auth>`, then send a message with an inline keyboard to yourself. This allows you to
+test your filter by pressing the inline button:
 
 .. code-block:: python
 
@@ -137,7 +137,7 @@ keyboard to yourself. This allows you to test your filter by pressing the inline
 Basic Filters
 ^^^^^^^^^^^^^
 
-For this basic filter we will be using only the first two parameters of :meth:`Filters.create() <pyrogram.Filters.create>`.
+For this basic filter we will be using only the first two parameters of :meth:`~pyrogram.Filters.create`.
 
 The code below creates a simple filter for hardcoded, static callback data. This filter will only allow callback queries
 containing "Pyrogram" as data, that is, the function *func* you pass returns True in case the callback query data
@@ -175,7 +175,7 @@ Filters with Arguments
 ^^^^^^^^^^^^^^^^^^^^^^
 
 A much cooler filter would be one that accepts "Pyrogram" or any other data as argument at usage time.
-A dynamic filter like this will make use of the third parameter of :meth:`Filters.create() <pyrogram.Filters.create>`.
+A dynamic filter like this will make use of the third parameter of :meth:`~pyrogram.Filters.create`.
 
 This is how a dynamic custom filter looks like:
 

docs/source/topics/more-on-updates.rst

@@ -1,7 +1,8 @@
 More on Updates
 ===============
 
-Here we'll show some advanced usages when working with `update handlers`_ and `filters`_.
+Here we'll show some advanced usages when working with :doc:`update handlers <../start/updates>` and
+:doc:`filters <filters>`.
 
 Handler Groups
 --------------
@@ -44,7 +45,7 @@ Or, if you want ``just_text`` to be fired *before* ``text_or_sticker`` (note ``-
     def just_text(client, message):
         print("Just Text")
 
-With :meth:`add_handler() <pyrogram.Client.add_handler>` (without decorators) the same can be achieved with:
+With :meth:`~pyrogram.Client.add_handler` (without decorators) the same can be achieved with:
 
 .. code-block:: python
 
@@ -217,6 +218,3 @@ The output of both (equivalent) examples will be:
     0
     1
     2
-
-.. _`update handlers`: ../start/updates
-.. _`filters`: filters

docs/source/topics/serialize.rst

@@ -9,7 +9,8 @@ For Humans - str(obj)
 ---------------------
 
 If you want a nicely formatted, human readable JSON representation of any object in the API -- namely, any object from
-`Pyrogram types`_, `raw functions`_ and `raw types`_ -- you can use use ``str(obj)``.
+:doc:`Pyrogram types <../api/types>`, :doc:`raw functions <../telegram/functions/index>` and
+:doc:`raw types <../telegram/types/index>` -- you can use use ``str(obj)``.
 
 .. code-block:: python
 
@@ -25,10 +26,6 @@ If you want a nicely formatted, human readable JSON representation of any object
     When using ``print()`` you don't actually need to use ``str()`` on the object because it is called automatically, we
     have done that above just to show you how to explicitly convert a Pyrogram object to JSON.
 
-.. _Pyrogram types: ../api/types
-.. _raw functions: ../telegram/functions
-.. _raw types: ../telegram/types
-
 For Machines - repr(obj)
 ------------------------
 

docs/source/topics/session-settings.rst

@@ -5,7 +5,7 @@ As you may probably know, Telegram allows users (and bots) having more than one
 in the system at the same time.
 
 Briefly explaining, sessions are simply new logins in your account. They can be reviewed in the settings of an official
-app (or by invoking `GetAuthorizations <../telegram/functions/account/GetAuthorizations.html>`_ with Pyrogram). They
+app (or by invoking :class:`~pyrogram.api.functions.account.GetAuthorizations` with Pyrogram). They
 store some useful information such as the client who's using them and from which country and IP address.
 
 .. figure:: https://i.imgur.com/YaqtMLO.png

docs/source/topics/smart-plugins.rst

@@ -65,8 +65,8 @@ after importing your modules, like this:
         app.run()
 
 This is already nice and doesn't add *too much* boilerplate code, but things can get boring still; you have to
-manually ``import``, manually :meth:`add_handler() <pyrogram.Client.add_handler>` and manually instantiate each
-:obj:`MessageHandler <pyrogram.MessageHandler>` object because **you can't use those cool decorators** for your
+manually ``import``, manually :meth:`~pyrogram.Client.add_handler` and manually instantiate each
+:class:`~pyrogram.MessageHandler` object because **you can't use those cool decorators** for your
 functions. So, what if you could? Smart Plugins solve this issue by taking care of handlers registration automatically.
 
 Using Smart Plugins
@@ -80,7 +80,7 @@ Setting up your Pyrogram project to accommodate Smart Plugins is pretty straight
 
 .. note::
 
-    This is the same example application `as shown above <#introduction>`_, written using the Smart Plugin system.
+    This is the same example application as shown above, written using the Smart Plugin system.
 
 .. code-block:: text
     :emphasize-lines: 2, 3
@@ -156,7 +156,7 @@ found inside each module will be, instead, loaded in the order they are defined,
 .. note::
 
     Remember: there can be at most one handler, within a group, dealing with a specific update. Plugins with overlapping
-    filters included a second time will not work. Learn more at `More on Updates <more-on-updates>`_.
+    filters included a second time will not work. Learn more at :doc:`More on Updates <more-on-updates>`.
 
 This default loading behaviour is usually enough, but sometimes you want to have more control on what to include (or
 exclude) and in which exact order to load plugins. The way to do this is to make use of ``include`` and ``exclude``
@@ -288,9 +288,8 @@ also organized in subfolders:
 Load/Unload Plugins at Runtime
 ------------------------------
 
-In the `previous section <#specifying-the-plugins-to-include>`_ we've explained how to specify which plugins to load and
-which to ignore before your Client starts. Here we'll show, instead, how to unload and load again a previously
-registered plugin at runtime.
+In the previous section we've explained how to specify which plugins to load and which to ignore before your Client
+starts. Here we'll show, instead, how to unload and load again a previously registered plugin at runtime.
 
 Each function decorated with the usual ``on_message`` decorator (or any other decorator that deals with Telegram updates
 ) will be modified in such a way that, when you reference them later on, they will be actually pointing to a tuple of
@@ -318,7 +317,7 @@ Unloading
 ^^^^^^^^^
 
 In order to unload a plugin, or any other handler, all you need to do is obtain a reference to it by importing the
-relevant module and call :meth:`remove_handler() <pyrogram.Client.remove_handler>` Client's method with your function
+relevant module and call :meth:`~pyrogram.Client.remove_handler` Client's method with your function
 name preceded by the star ``*`` operator as argument. Example:
 
 -   ``main.py``
@@ -343,7 +342,7 @@ Loading
 ^^^^^^^
 
 Similarly to the unloading process, in order to load again a previously unloaded plugin you do the same, but this time
-using :meth:`add_handler() <pyrogram.Client.add_handler>` instead. Example:
+using :meth:`~pyrogram.Client.add_handler` instead. Example:
 
 -   ``main.py``
 

docs/source/topics/text-formatting.rst

@@ -12,7 +12,7 @@ Markdown Style
 --------------
 
 To use this mode, pass "markdown" in the *parse_mode* field when using
-:obj:`send_message() <pyrogram.Client.send_message>`. Use the following syntax in your message:
+:meth:`~pyrogram.Client.send_message`. Use the following syntax in your message:
 
 .. code-block:: text
 
@@ -34,7 +34,7 @@ To use this mode, pass "markdown" in the *parse_mode* field when using
 HTML Style
 ----------
 
-To use this mode, pass "html" in the *parse_mode* field when using :obj:`send_message() <pyrogram.Client.send_message>`.
+To use this mode, pass "html" in the *parse_mode* field when using :meth:`~pyrogram.Client.send_message`.
 The following tags are currently supported:
 
 .. code-block:: text