Proposed fix #29

[hodgesmr]

One of my intentional design decisions in this project was that the output html would overwrite itself. Given many conversations I've read on Mastodon, I'm quite hesitant to create persistent archives outside the federated system. As such, this tool is fairly opinionated to be ephemeral. I suppose one could evade that now by creating unique output_dir on every run, or as is the case with other forks, committing output html to git histories.

Can you say more about your intended usecase?

[leoluecken]

The use case for me was that I liked the persistence since that allowed me to come back to the generated indices later (say if I automatically generate a digest every 12 hours or so - perhaps even several ones with different scorers). It was also convenient for comparing results during development.

But I see your argument, too, and defaulting to the render/index.html may be the best in that spirit. (Although, again, it is not much of a hindrance to persistent storing.)

You could still use the patch to allow also giving an output filename (instead to the directory) and revert the code, which manages the automated outfile naming in render_digest()

Would you like me to re-issue a pull request for that?

[hodgesmr]

Sorry for the long delay here. I've been toying with this a bit, and I like the idea of passing a specific path (rather than a directory and getting an auto-generated path). One question on that: what's the best way to handle the make target so that it keeps the convenience of auto-launching the output? Right now it's tangled up in the FLAGS var. If you have a good idea on that, I'd be interested in an update.

[leoluecken]

Hu, I don't really understand the Makefile-magic going on there. One quick-and-dirty way to keep the auto-launch convenience would obviously be to always write the last rendered html (additionally) to render/index.html, even if a specific path was given (the latter serving as a backup copy so to say).

[hodgesmr]

I truly appreciate the interest in iterating on this tool. I hope folks can find home in their unique forks. Please see the update in the readme:

⚠️ Update, 2023-05-21: Mastodon Digest is currently in maintenance-only mode. I do not have the capacity to continue fielding feature requests or PRs that fundamentally alter the way the tool works. If you have an idea for a new feature, forks are encouraged. I will continue to push updates for bug or security fixes. If you're looking for options that are more actively maintained, I suggest: Fediview or this fork. I'm heartened by how much positive attention this got among many Mastodon communities. For me this was always a toy. I'm glad I could push some open source code that gave people room to experiment.