Merge branch 'develop' into asyncio

# Conflicts:
#	pyrogram/client/types/messages_and_media/message.py

docs/source/faq.rst

@@ -185,9 +185,12 @@ IP addresses are now kept as aliases.
     DC2, "AMS, Amsterdam, NL", ``149.154.167.40``, ``2001:67c:4e8:f002::e``
     DC3*, "MIA, Miami FL, USA", ``149.154.175.117``, ``2001:b28:f23d:f003::e``
 
+.. centered:: More info about the Test Environment can be found :doc:`here <topics/test-servers>`.
+
 ***** Alias DC
 
-More info about the Test Environment can be found :doc:`here <topics/test-servers>`.
+Thanks to `@FrayxRulez <https://t.me/tgbetachat/104921>`_ for telling about alias DCs.
+
 
 I want to migrate my account from DCX to DCY.
 ---------------------------------------------
@@ -205,6 +208,36 @@ mechanism is also `confirmed <https://twitter.com/telegram/status/42713144665519
 it's currently not possible to have your account migrated, in any way, simply because the feature was once planned but
 not yet implemented.
 
+Thanks to `@gabriel <https://t.me/AnotherGroup/217699>`_ for confirming the feature was not implemented yet.
+
+Why is my client reacting slowly in supergroups?
+------------------------------------------------
+
+This issue affects only some supergroups or only some members within the same supergroup. Mostly, it affects supergroups
+whose creator's account (and thus the supergroup itself) lives inside a **different DC**, far away from yours, but could
+also depend on where a member is connecting from.
+
+Because of how Telegram works internally, every single message you receive from and send to other members must pass
+through the creator's DC, and in the worst case where you, the creator and another member all belong to three different
+DCs, the other member messages have to go through from its DC to the creator's DC and finally to your DC. This process
+will inevitably take its time.
+
+    To confirm this theory and see it by yourself, you can test in a supergroup where you are sure all parties live
+    inside the same DC. In this case the responses will be faster.
+
+Another reason that makes responses come slowly is that messages are **dispatched by priority**. Depending on the kind
+of member, some users receive messages faster than others and for big and busy supergroups the delay might become
+noticeable, especially if you are among the lower end of the priority list:
+
+1. Creator.
+2. Administrators.
+3. Bots.
+4. Mentioned users.
+5. Recent online users.
+6. Everyone else.
+
+Thanks to `@Manuel15 <https://t.me/PyrogramChat/76990>`_ for the priority list.
+
 I keep getting PEER_ID_INVALID error!
 -------------------------------------
 
@@ -222,7 +255,7 @@ UnicodeEncodeError: '<encoding>' codec can't encode …
 Where ``<encoding>`` might be *ascii*, *cp932*, *charmap* or anything else other than **utf-8**. This error usually
 shows up when you try to print something and has very little to do with Pyrogram itself as it is strictly related to
 your own terminal. To fix it, either find a way to change the encoding settings of your terminal to UTF-8 or switch to a
-better one.
+better terminal altogether.
 
 My verification code expires immediately!
 -----------------------------------------
@@ -248,7 +281,7 @@ Having said that, here's a list of what Telegram definitely doesn't like:
 - Spam, sending unsolicited messages or adding people to unwanted groups and channels.
 - Virtual/VoIP and cheap real numbers, because they are relatively easy to get and likely used for spam/flood.
 
-And here's a good explanation of how, probably, the system works:
+And thanks to `@koteeq <https://t.me/koteeq>`_, here's a good explanation of how, probably, the system works:
 
 .. raw:: html
 
@@ -257,8 +290,7 @@ And here's a good explanation of how, probably, the system works:
         data-telegram-post="PyrogramChat/69424"
         data-width="100%">
     </script>
-
-.. centered:: Join the discussion at `@Pyrogram <https://t.me/pyrogram>`_
+    <br><br>
 
 However, you might be right, and your account was deactivated/limited without any good reason. This could happen because
 of mistakes by either the automatic systems or a moderator. In such cases you can kindly email Telegram at

docs/source/intro/install.rst

@@ -47,7 +47,7 @@ Pyrogram heavily depends on IO-bound network code (it's a cloud-based messaging
 where asyncio shines the most by providing extra performance and efficiency while running on a single OS-level thread
 only.
 
-**A fully asynchronous variant of Pyrogram is therefore available** (Python 3.5.3+ required).
+**A fully asynchronous variant of Pyrogram is therefore available** (Python 3.5.3 or higher is required).
 Use this command to install (note "asyncio.zip" in the link):
 
 .. code-block:: text

docs/source/topics/storage-engines.rst

@@ -31,7 +31,7 @@ File Storage
 ^^^^^^^^^^^^
 
 This is the most common storage engine. It is implemented by using **SQLite**, which will store the session and peers
-details. The database will be saved to disk as a single portable file and is designed to efficiently save and retrieve
+details. The database will be saved to disk as a single portable file and is designed to efficiently store and retrieve
 peers whenever they are needed.
 
 To use this type of engine, simply pass any name of your choice to the ``session_name`` parameter of the
@@ -51,7 +51,7 @@ session database will be automatically loaded.
 Memory Storage
 ^^^^^^^^^^^^^^
 
-In case you don't want to have any session file saved on disk, you can use an in-memory storage by passing the special
+In case you don't want to have any session file saved to disk, you can use an in-memory storage by passing the special
 session name "**:memory:**" to the ``session_name`` parameter of the :obj:`~pyrogram.Client` constructor:
 
 .. code-block:: python
@@ -61,16 +61,12 @@ session name "**:memory:**" to the ``session_name`` parameter of the :obj:`~pyro
     with Client(":memory:") as app:
         print(app.get_me())
 
-This database is still backed by SQLite, but exists purely in memory. However, once you stop a client, the entire
-database is discarded and the session details used for logging in again will be lost forever.
+This storage engine is still backed by SQLite, but the database exists purely in memory. This means that, once you stop a
+client, the entire database is discarded and the session details used for logging in again will be lost forever.
 
 Session Strings
 ---------------
 
-Session strings are useful when you want to run authorized Pyrogram clients on platforms like
-`Heroku <https://www.heroku.com/>`_, where their ephemeral filesystems makes it much harder for a file-based storage
-engine to properly work as intended.
-
 In case you want to use an in-memory storage, but also want to keep access to the session you created, call
 :meth:`~pyrogram.Client.export_session_string` anytime before stopping the client...
 
@@ -81,8 +77,8 @@ In case you want to use an in-memory storage, but also want to keep access to th
     with Client(":memory:") as app:
         print(app.export_session_string())
 
-...and save the resulting string somewhere. You can use this string as session name the next time you want to login
-using the same session; the storage used will still be completely in-memory:
+...and save the resulting (quite long) string somewhere. You can use this string as session name the next time you want
+to login using the same session; the storage used will still be completely in-memory:
 
 .. code-block:: python
 
@@ -93,3 +89,11 @@ using the same session; the storage used will still be completely in-memory:
     with Client(session_string) as app:
         print(app.get_me())
 
+Session strings are useful when you want to run authorized Pyrogram clients on platforms like
+`Heroku <https://www.heroku.com/>`_, where their ephemeral filesystems makes it much harder for a file-based storage
+engine to properly work as intended.
+
+But, why is the session string so long? Can't it be shorter? No, it can't. The session string already packs the bare
+minimum data Pyrogram needs to successfully reconnect to an authorized session, and the 2048-bits auth key is the major
+contributor to the overall length. Needless to repeat that this string, as well as any other session storage, represent
+strictly personal data. Keep them safe.

pyrogram/client/types/messages_and_media/message.py

@@ -727,6 +727,8 @@ class Message(Object, Update):
             reply_markup=reply_markup
         )
 
+    reply = reply_text
+
     async def reply_animation(
         self,
         animation: str,
@@ -2409,6 +2411,8 @@ class Message(Object, Update):
             reply_markup=reply_markup
         )
 
+    edit = edit_text
+
     async def edit_caption(
         self,
         caption: str,