Fix merge conflicts

docs/source/Howtos/Tutorial-Persistent-Handler.md

@@ -24,7 +24,7 @@ class NameChanger:
 class MyObject(DefaultObject):
     @lazy_property:
     def namechange(self):
-       return MyHandler(self)
+       return NameChanger(self)
 
 
 obj = create_object(MyObject, key="test")
@@ -35,13 +35,23 @@ print(obj.key)
 >>> "test_extra"
 ```
 
-What happens here is that we make a new class `MyHandler`. We use the `@lazy_property` decorator to set it up - this means the handler will not be actually created until someone really wants to use it, by accessing `obj.namechange` later. The decorated `namechange` method returns the handler and makes sure to initialize it with `self` - this becomes the `obj` inside the handler! 
+What happens here is that we make a new class `NameChanger`. We use the
+`@lazy_property` decorator to set it up - this means the handler will not be
+actually created until someone really wants to use it, by accessing
+`obj.namechange` later. The decorated `namechange` method returns the handler
+and makes sure to initialize it with `self` - this becomes the `obj` inside the
+handler!
 
-We then make a silly method `add_to_key` that uses the handler to manipulate the key of the object. In this example, the handler is pretty pointless, but grouping functionality this way can both make for an easy-to-remember API and can also allow you cache data for easy access - this is how the `AttributeHandler` (`.attributes`) and `TagHandler` (`.tags`) works. 
+We then make a silly method `add_to_key` that uses the handler to manipulate the
+key of the object. In this example, the handler is pretty pointless, but
+grouping functionality this way can both make for an easy-to-remember API and
+can also allow you cache data for easy access - this is how the
+`AttributeHandler` (`.attributes`) and `TagHandler` (`.tags`) works.
 
 ## Persistent storage of data in handler
 
-Let's say we want to track 'quests' in our handler. A 'quest' is a regular class that represents the quest. Let's make it simple as an example: 
+Let's say we want to track 'quests' in our handler. A 'quest' is a regular class
+that represents the quest. Let's make it simple as an example:
 
 ```python
 # for example in mygame/world/quests.py
@@ -103,7 +113,6 @@ class QuestHandler:
         self._save()
 
     def check_progress(self):
-        for quest in self.storage.values():
             quest.check_progress()
         if self.do_save:
             # .do_save is set on handler by Quest if it wants to save progress
@@ -159,9 +168,18 @@ class Quest:
 
 ```
 
-The `Quest.__init__` now takes `obj` as argument, to match what we pass to it in `QuestHandler.add`. We want to monitor the changing of `current_step`, so we make it into a `property`. When we edit that value, we set the `do_save` flag on the handler, which means it will save the status to database once it has checked progress on all its quests.
+The `Quest.__init__` now takes `obj` as argument, to match what we pass to it in
+`QuestHandler.add`. We want to monitor the changing of `current_step`, so we
+make it into a `property`. When we edit that value, we set the `do_save` flag on
+the handler, which means it will save the status to database once it has checked
+progress on all its quests. The `Quest.questhandler` property allows to easily
+get back to the handler (and the object on which it sits).
 
-The `__serialize__dbobjs__` and `__deserialize_dbobjs__` methods are needed because `Attributes` can't store 'hidden' database objects (the `Quest.obj` property. The methods help Evennia serialize/deserialize `Quest` propertly when the handler saves it.  For more information, see [Storing Single objects](../Components/Attributes.md#storing-single-objects) in the Attributes documentation. 
+The `__serialize__dbobjs__` and `__deserialize_dbobjs__` methods are needed
+because `Attributes` can't store 'hidden' database objects (the `Quest.obj`
+property. The methods help Evennia serialize/deserialize `Quest` propertly when
+the handler saves it.  For more information, see [Storing Single
+objects](../Components/Attributes.md#storing-single-objects) in the Attributes
 
 ### Tying it all together
 
@@ -184,14 +202,21 @@ class Character(DefaultCharacter):
 ```
 
 
-You can now make your Quest classes to describe your quests and add them to characters with 
+You can now make your Quest classes to describe your quests and add them to
+characters with
 
+```python
 character.quests.add(FindTheRedKey)
+```
 
 and can later do
 
+```python
 character.quests.check_progress()
+```
 
 and be sure that quest data is not lost between reloads.
 
-You can find a full-fledged quest-handler example as  [EvAdventure quests](evennia.contribs.tutorials.evadventure.quests) contrib in the Evennia repository.
+You can find a full-fledged quest-handler example as  [EvAdventure
+quests](evennia.contribs.tutorials.evadventure.quests) contrib in the Evennia
+repository.

evennia/contrib/rpg/rpsystem/rplanguage.py

@@ -17,7 +17,7 @@ in the game in various ways:
     overhear (for example "s" sounds tend to be audible even when no other
     meaning can be determined).
 
-Usage:
+## Usage
 
 ```python
 from evennia.contrib import rplanguage
@@ -48,15 +48,38 @@ Usage:
 
 ```
 
-    To set up new languages, import and use the `add_language()`
+## Custom languages
-    helper method in this module. This allows you to customize the
+
-    "feel" of the semi-random language you are creating. Especially
+To set up new languages, you need to run `add_language()`
+helper function in this module. The arguments of this function (see below)
+are used to store the new language in the database (in the LanguageHandler,
+which is a type of Script).
+
+If you want to remember the language definitions, you could put them all
+in a module along with the `add_language` call as a quick way to
+rebuild the language on a db reset:
+
+```python
+# a stand-alone module somewhere under mygame. Just import this
+# once to automatically add the language!
+
+from evennia.contrib.rpg.rpsystem import rplanguage
+grammar = (...)
+vowels = "eaouy"
+# etc
+
+rplanguage.add_language(grammar=grammar, vowels=vowels, ...)
+```
+
+The variables of `add_language` allows you to customize the "feel" of
+the semi-random language you are creating. Especially
 the `word_length_variance` helps vary the length of translated
-    words compared to the original and can help change the "feel" for
+words compared to the original. You can also add your own
-    the language you are creating. You can also add your own
 dictionary and "fix" random words for a list of input words.
 
-    Below is an example of "elvish", using "rounder" vowels and sounds:
+## Example
+
+Below is an example module creating "elvish", using "rounder" vowels and sounds:
 
 ```python
 # vowel/consonant grammar possibilities
@@ -115,12 +138,12 @@ Usage:
 
 """
 import re
-from random import choice, randint
 from collections import defaultdict
+from random import choice, randint
+
 from evennia import DefaultScript
 from evennia.utils import logger
 
-
 # ------------------------------------------------------------
 #
 # Obfuscate language