The map plugin has inconsistent behaviour. In particular, I have in my wiki some directory structures holding files without wikitext pointers (I point directly to the files from elsewhere). For example, imagine the following file structure in the source dir:
; ls -R dirA dirB dirA: subA subB dirA/subA: filea.mdwn fileb.mdwn dirA/subB: filec.mdwn filed.mdwn dirB: subA subC dirB/subA: filea.mdwn dirB/subC: fileb.mdwn filec.mdwn
When I use map to make a map of this, the result looks more like this:
Note that while the dirA/subA directory exists with a create link, the dirA/subB directory is missing from the map. Interestingly, dirB/subC is shown in the map. If you add a second file to dirB/subA then dirB/subC disappears as well.
I could imagine including all 'bare' directories in the map, and I could imagine including no 'bare' directories in the map. Just including the first bare directory seems a strange intermediate point.
Attached is a patch that fixes the issue. The current map code makes one pass over the sorted list of pages. This adds an initial pass that goes through and makes sure that all parent directories are included. With this initial pass added, the following pass could probably be simplified.
One solution could also use the autoindex plugin to make sure that parent pages actually exist. This is really only a stop-gap solution until the patch is applied - map still needs to be made bug-free.
Note: This patch adds items to a map while it is in a foreach loop over a sorted list of keys from that same map. Changing a map while iterating through it is normally problematic. I'm assuming the sort insulates the code from this - I do not need to iterate over any of the newly added elements.
The patch is subtly buggy and just papers over the actual bug with a lot of extra code. Thanks for trying to come up with a patch for this annyoingly complicated bug.. I think I've fixed the underlying bug now. --Joey