## sort= parameter

Having a `sort=` parameter for the map plugin/directive would be real nice; like `inline`'s parameter, with `age`, `title`, etc.

I may hack one in from `inline` if it seem within my skill level.

> this could leverage the [[sorting mechanism|ikiwiki/pagespec/sorting]] already in place. as it's not sorting a flat list, there's a number of different ways to sort, which should be configurable imo.
>
> as an example, i'll consider pages created in the sequence c/1, a, b, c, a/1, c/2.
>
> sorting could:
>
> * sort within each level:
>
>   sorting order of child nodes would only matter internally in the groups
>
>   that would create a (a/1) b c (c/1 c/2) sequence in our example.
>
> * sort by maximum
>
>   the highest ranking page in a group would pull the parent to its own position
>
>   that would create b a (a/1) c (c/1 c/2).
>
> * sort by minimum
>
>   the lowest ranking page in a group would pull the parent to its own position
>
>   here, that would give c (c/1 c/2) a (a/1) b
>
> * forced sequence
>
>   all deepest-level items are forced to their positions, even if that means their parents are repeated at positions where they wouldn't occur naturally. parent nodes that don't have child nodes that occur directly before or after them are shown without the child nodes.
>
>   that'd be c (c/1) a b c a (a/1) c (c/2) in our example.
>
>   admittedly, the use cases for that are not too obvious, but think of a travel diary, for example, where you'd have the entries chronologically but grouped by the country you've visited. when you visit the same country twice, it should show up twice too.
>
> --[[chrysn]]

------

> i now do have two thirds of the solution:
>
> * i've patched the map plugin to accept a sort parameter (as usual in pagespec directives) and a strategy parameter, which is used to choose how the tree should be sorted. it turned out that the changes required were minimal; even precautions for having to display a node's parents although they are not supposed to be shown by themselves are present (they're decorated with the mapparent css class).
> * i've implemented algorithms for the described strategies, but in python -- i tried in perl, but i'm not versed well enough in perl for such things. the "force" strategy works in perl but i'm afraid it depends on more than the perl sort algorithm to be just stable.
> * if someone could port the three strategies implemented in python to perl, we'd have a complete patch for this.
>
> when comparing the implementation to my notes above, you'll see that there is a minor difference in the "force" algorithm -- my code doesn't generate the "parent" entries (**c** (c/1) a b c **a** (a/1) **c** (c/2) in the example), but they're generated by the already existing output code.
>
> the code can be found at [[incomplete_patch.pl.pl]] and [[python_algorithms.py]]. --[[chrysn]]

[[!tag wishlist]]
