The issue is that, within the current framework, we only know about the given channel's parent. So for a channel – it's the category, and for a thread – it's the parent channel.

We could try to add a new token that evaluates to the full path (what to name it?), but we would have to pull that information early and embed it within the Channel object.

Nevermind, we should be able to evaluate the full path as is. I still think we need a new token for this, but I'm not sure. Thoughts?

I can propose the following solution: %r/%R token that evaluates to the root parent's id/name. In case with a channel, it would be the category, and in case with a thread, it would be the parent channel. Would that work? @CanePlayz

I can propose the following solution: %r/%R token that evaluates to the root parent's id/name. In case with a channel, it would be the category, and in case with a thread, it would be the parent channel. Would that work? @CanePlayz

Isn't that what – according to my example above – %T already does currently? It returns the category as the parent of the channel and the parent channel as the parent of the thread...

What we'd essentially really want there is to be able to access the category when exporting a thread instead of only accessing its parent channel, so that a structure like this could be achieved:

Server name
|
|-- Category name 1
|     |
|     |-- Channel name 1 
|     |-- Channel name 2
|     |-- Threads of Channel name 1
|     |     |-- Thread of channel 1

Isn't that what – according to my example above – %T already does currently? It returns the category as the parent of the channel and the parent channel as the parent of the thread...

Sorry, you're right. I mistyped. In case of a thread it would also be the category.

What we'd essentially really want there is to be able to access the category when exporting a thread instead of only accessing its parent channel, so that a structure like this could be achieved:

I'm a bit wary about making assumptions anymore, after Discord added threads. In this case, it's better to expect that channels might eventually have deeper hierarchy than 1 or 2 levels, or that there might be channels that are completely outside of categories.

One thing we can expose is the hierarchical name of the channel/thread as one token -- i.e. %H ⇒ Category - Channel - Thread. But then the delimiter would have to be baked in.

The issue with the root parent token proposal is that for channels both %R and %T would be the same, so you'd have to use different templates regardless.

Sorry, you're right. I mistyped. In case of a thread it would also be the category.

Interesting. I like the general idea of that as it would behave differently for channels and threads and therefore only require one path argument. However, it would limit the folder and file names to just being the plain category/channel name without extra modifications.

One thing we can expose is the hierarchical name of the channel/thread as one token -- i.e. %H ⇒ Category - Channel - Thread. But then the delimiter would have to be baked in.

Yeah, same concern as the one above.

The issue with the root parent token proposal is that for channels both %R and %T would be the same, so you'd have to use different templates regardless.

Yeah, the solution with two added tokens would require separate arguments for channel and thread paths, so while it might look elegant at first, it might not be that easy to implement.

There is an another option - let user export only threads without channel. Then the user can run two commands - first one to export channels, second one to export threads - for each command the user can pass different path (achieving option 1)

There is an another option - let user export only threads without channel. Then the user can run two commands - first one to export channels, second one to export threads - for each command the user can pass different path (achieving option 1)

This is already the case. I'm assuming @CanePlayz's issue is when you export multiple types of channels at once.

• For threads, evaluate the same term for the parent channel and put the threads inside whatever folder their parent channel is in.

This could work, but it might be confusing that the supplied path is actually for the parent channel (which may or may not be exported at the same time), and that the actual path will be somewhat different.

• For threads, evaluate the same term for the parent channel and put the threads inside whatever folder their parent channel is in.

This could work, but it might be confusing that the supplied path is actually for the parent channel (which may or may not be exported at the same time), and that the actual path will be somewhat different.

Yup, that would be confusing and also limit the possible paths quite hard.