TitleIndex Macro should also take relative prefixes

[glinders@…]

The TitleIndex macro only takes the full path of a Wiki page.

For instance, if you are on Wiki page WikiStart:Top/Deeper/Deepest and want to include a list of all subpages of Deepest, you have to include [[TitleIndex(Top/Deeper/Deepest/)]] in your page.

It would be great if you could also use [[TitleIndex(./)]] to achieve the same.

Similarly, [[TitleIndex(../)]] should give the same result as [[TitleIndex(Top/Deeper/)]]

[Peter Suter]

The attached patch​ implements this functionality that I've been missing myself.

[Jun Omae]

I tried the patch. It is inconsistent between [[TitleIndex(./)]] and [[TitleIndex(SandBox/)]].

Also, we should add unit tests for this feature.

[Peter Suter]

Thanks for testing. You are of course correct on both accounts. I will attach an updated patch later.

[Peter Suter]

Replying to jomae:

It is inconsistent between [[TitleIndex(./)]] and [[TitleIndex(SandBox/)]]. Also, we should add unit tests for this feature.

This updated patch​ fixes the inconsistency ([[TitleIndex(./)]] does not list the current wiki page anymore) and adds unit tests.

(The fix is changing _resolve_relative_name:

-elif comp and comp != '.': 
+elif comp != '.': 

It is not immediately obvious that this breaks no other callers, but I can not come up with a scenario where this change would affect the only other caller​ after pagename.rstrip('/') and pagename.startswith(('./', '../')) or pagename in ('.', '..').)

[Jun Omae]

(The fix is changing _resolve_relative_name:

-elif comp and comp != '.': 
+elif comp != '.': 

It is not immediately obvious that this breaks no other callers, but I can not come up with a scenario where this change would affect the only other caller​ after pagename.rstrip('/') and pagename.startswith(('./', '../')) or pagename in ('.', '..').)

After the changes, in SandBox page,

• ..//WikiStart will be WikiStart? text
• ../WikiStart will link to WikiStart page

Before the changes, both will link to WikiStart page.

But I think the patch is okay because page name doesn't have repeated-slashes.

Unit and functional tests pass on Python 2.5 - 2.7 with SQLite, PostgreSQL and MySQL on Linux.

[Peter Suter]

Committed in [12584]. Thanks for reviewing and testing. I had not considered such "invalid" page names with repeated slashes.

[Ryan J Ollos]

How does the following documentation update look?

trac/wiki/macros.py

@@ -84 +84 @@
     """Insert an alphabetic list of all wiki pages into the output.
 
     Accepts a prefix string as parameter: if provided, only pages with names
-    that start with the prefix are included in the resulting list. If this
-    parameter is omitted, all pages are listed.
-    If the prefix is specified, a second argument of value `hideprefix`
-    can be given as well, in order to remove that prefix from the output.
+    that start with the prefix are included in the resulting list. The
+    commonly-used relative-path notation is supported: a prefix string
+    starting with `./` will be relative to the current page, and parent pages
+    can be specified using `../`. If this parameter is omitted, all pages are
+    listed. If the prefix is specified, a second argument of value
+    `hideprefix` can be given as well, in order to remove that prefix from
+    the output.
 
     Alternate `format` and `depth` named parameters can be specified:
      - `format=compact`: The pages are displayed as comma-separated links.

[Peter Suter]

Your proposed text sounds fine.

I didn't think a documentation update was necessary as it seemed just like a standard use of wiki:TracLinks#Relativelinks. But documenting it explicitly doesn't hurt.

More details that may or may not be obvious:

• ./ is probably the most common use case, but this is not restricted just to plain ./ and ../. E.g. on TracDev one might use ./ReleaseNotes/. (More complex combinations like ../../Wiki and even ./.././.././Wiki also "work".)
• These only work on wiki pages, while absolute prefixes could also be used here in a ticket comment for example.

[Ryan J Ollos]

Sorry for the delay. Documentation change committed to trunk in [13014].

[Ryan J Ollos]

Just FYI, the changes to TitleIndex macro in this ticket provide equivalent functionality to the old SubWiki macro (​th:HierWikiPlugin). I've marked HierWikiplugin as deprecated since it doesn't work with at least Trac 1.0 and later.