What would this placeholder do? I'm not sure I get the idea behind it...

Sorry - this lacks a little description.

The idea was to evaluate some parts of the export path-schema recursively (iterating through the parent channels).
See #1123 - here it was discussed that we can not use "%T" to put Threads into the same folder as the owner Channel.
With this recursive call you can achieve this now because the code will update the output path as the following:

Inital path pattern: \%G\%P – %T\%p – %C.html
updated path pattern: \%G\%r%P – %T%r\%p – %C.html

so on the first iteration will find the regex group: %P – %T
the value of the group will be forwarded again to "FormatPath" with the parent-channel as context - which than look like:
\%G\{Channel.Parent.Parent.Position} - {Channel.Parent.Parent.Name}\%p – %C.html

the updated path will than be used to replace the leftover placeholder values:
\{Guild.Name}\{Channel.Parent.Parent.Position} - {Channel.Parent.Parent.Name}\{Channel.Position} – {Channel.Name}.html

After looking through it today again this could be more optimized but i think the conceptional idea / solution is still fine

Thanks for the thorough explanation. It is certainly an interesting approach.

What I originally wanted to achieve was this:

Server name (folder)
|
|-- Category name 1 (folder)
      |
      |-- Channel name 1 (file)
      |
      |-- Channel name 2 (file)
      |
      |-- Channel name 1 (folder)
            |
            |-- Thread of channel 1 (file)

Or differently expressed: Would %r%P – %r%T result in
.../Category Pos – Category Name/Parent Channel Pos – Parent Channel Name/Thread.json for a thread?

Edit:

Just tested it now that it has been built, and I get it now. This puts the threads into the same folder as the parent channel with the thread having the same naming structure as its parent channel. Rather than creating another folder inside the same directory as that of the parent channel, which is what I had imagined in the initial issue and above.

It would after all still limit the options of how you can format the parent channel part since its structure would be inherited from the category structure, but I don't think that would be an issue as most people have these symmetrical approaches anyways.

@CanePlayz can you comment whether this PR fully addresses #1123, as reported by you?

This puts the threads into the same folder as the parent channel with the thread having the same naming structure as its parent channel. Rather than creating another folder inside the same directory as that of the parent channel, which is what I had imagined in the initial issue and above.

Unfortunately not. I guess it'd still be an enhancement, but:

This new method puts the thread files into the same folder as the parent channel files with the thread having the same naming structure as its parent channel. What I had imagined in the initial issue was creating another folder inside the same directory as that of the parent channel where all the threads would be stored (you can see that desired structure above).

However, a possible solution to this could be introducing new parameters that are thread-exclusive (meaning if the channel being processed is a normal one, they are just being ignored, but if the channel is a thread, they are indeed being resolved to for example the name of the parent channel or its position.

I should be able to code this myself, will update you.

I think this is an interesting design, but I don't want to make placeholders too complicated. Adding parametrized recursion opens the door to a fully programmatic DSL inside filename templates, which could definitely be useful, but not necessarily something I want to support. I think we should offer basic templating support, but mostly defer to bulk renaming tools to let the user establish more tailored file structures.