Tyrrrz / DiscordChatExporter

Exports Discord chat logs to a file
MIT License
7.48k stars 682 forks source link

Make template tokens work properly for export paths of threads #1123

Open CanePlayz opened 1 year ago

CanePlayz commented 1 year ago

Version

v2.40.4

Flavor

GUI (Graphical User Interface), CLI (Command-Line Interface)

Platform

Any

Export format

No response

Steps to reproduce

Export threads and use template tokens in the path

Details

Path parameters need to be rethought with threads because DCE uses the same given path for both channels and threads. That messes with threads. Let's look at the following example:

\\%G\\%P – %T\\%p – %C.html

It essentially means:

Server\\Category\\Channel.html

This should result in the following structure:

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

If I export a channel, the term gets evaluated properly.

However, if I export a thread, the term doesn't get evaluated properly. Here's why:

%P – %T will evaluate to the parent channel, because that is "the thread's category", instead of using the server-level category.

Ultimately, this means that you will end up with something like this:

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

Possible solutions would be:

The first option would be more flexible, and clearer to the user. However, we'd need two more parameters: one for the name of a parent channel and one for a thread's name.

Checklist

Tyrrrz commented 1 year ago

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.

Tyrrrz commented 1 year ago

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?

Tyrrrz commented 1 year ago

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

CanePlayz commented 1 year ago

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
Tyrrrz commented 1 year ago

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.

Tyrrrz commented 1 year ago

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. %HCategory - 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.

CanePlayz commented 1 year ago

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.

slatinsky commented 1 year ago

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)

Tyrrrz commented 1 year ago

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.

Tyrrrz commented 1 year ago
  • 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.

CanePlayz commented 1 year ago
  • 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.