Except that none of the suggested options actually respect the given constraints, i.e. a plugin that can robustly interoperate with other plugins in the same wiki, without third party dependencies. Arguing the merits of the constraints is fair but it is not the same as providing a solution for them.
-
Overriding user interface elements is inherently brittle in a wiki that might use other plugins that may also do the same, or provide alternative UI affordances for deleting a tiddler. Every single user that used another plugin and/or wikitext code provided by someone else would potentially be at risk of running into problems, even if they themselves never directly used action-deletetiddler.
-
The MessageCatcher and EventCatcher widgets cannot intercept hooks or the action-deletetiddler widget. It was the advice to explore this option that prompted me to participate in this thread, so as to save anyone the trouble of exploring this dead end. Neither can either of these widgets be used to capture messages or events in the entirety of a wiki without overriding shadow tiddlers, another point of brittleness for a plugin that aims to interoperate smoothly with other plugins.
-
The advice to use Relink neither addresses the need to respond to the action-deletetiddler widget, nor the desire to avoid third party dependencies which can be a failure point. My experience with Streams has been that despite documentation, the dependency on Relink is the most common failure point for users, to the extent that I had to start distributing Relink alongside Streams in the same plugin library so that it would be automatically installed.
So is there a valid solution for intercepting action-deletetiddler within the given constraints that I have missed?
If the designer intercepts at a lower level an attempt to use an action, such as delete, you limit the customisability and ease of understanding of your solution, perhaps even damage the ability for someone to repair a broken wiki.
A heads up that Streams does this, so you may want to take that into account for any potential future usage of the plugin.
I am personally of the opinion that implementing features with robust tiddler relation handling are best done through bespoke TiddlyWiki editions that are heavily customized and not necessarily marketed as interoperable with all other plugins and customizations. Constraints can often lead to a better and more robust user experience.
However, I think it is an admirable goal to try and write plugins that can interoperate with other plugins and be robust and usable in a standard empty TiddlyWiki, and we should try to encourage and support this wherever possible. I would be happy to participate in any further discussion around how we can do so in practice for better handling tiddler relations, rather than debating the merit or need for such an approach.
Identifying the current limitations of wikitext is important as it allows us to understand where the core can be improved to allow greater flexibility and customizability via wikitext, ultimately further empowering TiddlyWiki users.