This solves two problems: first, the relationships are now defined in
the class they apply to, rather than in a separate section of the module,
and second, their metadata -- both creation arguments and extra info such
as `description` (or, later, possibly, info for API properties) -- is
stored.
Some code in spline-pokedex orders by `id`, which has worse consequences
than it may seem (e.g. instead of defaulting to most recent games, the
comparifier defaults to XD). This is the first step to fixing that.
I actually reripped all the D/P data, too, and compared them myself just
to be sure, but those four were all there was. (The other move from the
last commit was Poison Gas—we had its old accuracy right, remember.)
etree and AtomicString will be moved in python-markdown 2.1
See commit https://github.com/waylan/Python-Markdown/commit/89a4f3d0829a7 :
Cleaned up markdown namespace. This may be a backward incompatible
change for some extensions. They should be importing from
markdown.util
No reason to instantiate every time as_html's called, is there?
Also, sessions use a markdown_extension attribute instead of
markdown_extension_class. The latter is only used to set the former when
the session is created (unless another markdown_extension_class is given,
of course).
Links such as []{pokemon:mewthree} can come from users, so they should not
crash the parser.
So, when an object is not found (or more than one is found), call
identifier_url() directly, instead of failing to get the object for
object_url(). Essentially, treat the link as having an unknown category
(like mechanic:, currently).
The test that check the pokédex descriptions updated so that only
links to known objects and "mechanic:" are allowed.
Linked-to objects aren't required to have identifiers now, so object_url()
in custom extensions might need to be changed.
The one in the test did, for example.
Now results are sorted by is-this-your-language (times levenshtein
distance, if appropriate), then by rough class of result (Pokémon, then
moves, then abilities, etc.) and finally by name.
This fixes a couple issues:
- If both a foreign name and a local name matched a wildcard lookup,
you'll see the local name. Before, you'd see whichever happened to be
first alphabetically.
- Wildcard results are more likely to have useful stuff at the top,
rather than being dominated by foreign junk and names of obscure
locations.
This also updates our usage of the whoosh API, which was old and busted
as of 2.0 or so.
