[Plugin] TagMechanic

[Capricorn]

I have seen that Tagmechanic is one of the plugins that can be used in "automate list". Is it possible to set certain values in Tagmechanic eg delete, span, the regex you want to use, and then let it run automatically within the "automate list" without having any user interaction? Maybe via the json of Tagmechanic or is this a fixed file?

[DiapDealer]

That's not currently possible, no. But I will look into seeing what changes something along those lines might involve.

[Capricorn]

If at all possible, that would be very nice indeed.
Thank you for looking into it.

[KevinH]

FWIW, Automate list does allow a single text line to be passed to a plugin that you could parse to extract user supplied information.

[DiapDealer]

Yes. I'm imagining the string parameter will come in handy. I may even use it to to pass the name of a json file. One that could be saved from the current gui settings. The parsing engine is already completely isolated from the gui, so a headless run would not be terribly difficult to pull off (and saving the run data from a gui session would avoid needing to validate all of that data in the headless session). And though the selected files would be available, it may make more sense for a headless run to simply process all text/html files.

Lots to think about!

[DiapDealer]

I've got a proof-of-concept working without too much trouble. I'm going to wait until I have the ability to safely save/load multiple json configurations that can then be selected to use in a headless Automate List run by passing the unique file name (without the .json extension) as a parameter to the plugin before releasing a beta.

As it is right now, the new Save Config button saves the currently loaded config to a hardcoded "headless.json" file, and is picked up in an automated list by the same hardcoded file name. One has to:

1) save a config from the gui
2) check the "Plugin runs headless in Automate Lists" checkbox in the gui config dialog (it's unchecked by default because I don't want to mess up any existing automate lists that are already using TagMechanic as is), and then
3) add a SetPluginParameter tool (with any value for now) to an automated list before the TagMechanic plugin. This will eventually need to match the saved config file (minus the .json extension).

Just know that the headless config will run on ALL text files in the epub (not just the ones selected in Book Browser like in the GUI version). And that there are no guardrails like with the gui versions. No pre-commit report to approve of. The changes WILL be committed where found, so be certain your parameters are doing exactly what you want before saving your epub (or better yet, create a Sigil checkpoint so you can easily roll back any mistakes).

If you want to see any debug output, you'll need to temporarily change the autoclose tag in TagMechanic's plugin.xml file from true to false (and relaunch Sigil).

[BeckyEbook]

It works great!

Although I admit that a third launch mode is being born in my mind
1. Classic GUI.
2. Automate List with parameter.
3. A window asking to select a saved .json configuration and then run with or without GUI (to be considered).

IMHO without the ability to select the configuration the potential of the TagMechanic plugin will not be used. Looking at the posts from a few years ago in this thread – I think users were expecting just something like Saved Searches with the ability to select previously saved configurations.

For me, Automate List is more like a fairly fixed list of tasks performed one by one. And yet Tag Mechanic is a powerful enough tool that a list of saved configurations will be more flexible than Automate List.

If I had to edit the Automate List every time to change a parameter of a plugin, I would already be discouraged.

But being able to choose from the list... immediately puts a smile on my face.

To tell you the truth, I've been thinking about this for a few years now, and in my mind, this list was simply a ComboBox with a selection of a saved configuration that would simply refresh the fields in the plugin's window when selected. Maybe it only looks simple in my head, but it's as tedious as adding a new option in the Sigil Preferences window.

[DiapDealer]

We're on the same page! My plan is to add the ability to load saved configs in the gui as well. If only because saved configs need a way to be edited (rather than needing to delete them and recreate new ones).

I haven't decided on the best way yet, but your combobox idea definitely warrants a look. I don't know how simple any of it will turn out to be either, but I'm up for the challenge regardless.

One problem I may run into, is that as people change the the available tags in TagMechanic's config dialog, that will change the combobox indices that are saved in the new config jsons. There will need to be some robust error checking for sure.

[BeckyEbook]

I'm relieved.

Of course, I also wondered about people who (like me) edited their plugins by adding options that didn't exist in the original one.
But hopefully, good error handling for each entry should solve this problem.

I've also been thinking about the speed of the plugin and maybe ComboBox isn't the ideal solution (I wouldn't want to mess up your ideas).
Probably the maximum speed under ideal conditions could resemble, for example. Saved Sessions in PuTTY, where double-clicking on a saved entry calls two functions immediately: "Load" and "Run".

On the other hand, I do not know the average level of tech-savviness of Sigil and TagMechanic users, but such acceleration could lead to erroneous clicks.

These are difficult decisions that directly affect the ease of use of the plugin. I hope your experience will help you choose the optimal GUI solution.

[DiapDealer]

The good news is that the configs are being saved with the actual text/tag parameters, so in a headless run (and any potential minimal GUI run), things should just work. No validation needed since the validation takes place before the config can get successfully saved.

The challenge will be in loading the saved config into a full GUI run. There will need to be some sort of validation that maps text values to indices to make sure things have not been altered in the plugin customization that would cause combobox indices to change. And there would need to be something done to handle the situation where something in a saved config was subsequently removed from the plugin customization fields. Probably a rare situation -- but still possible.

[DiapDealer]

Also... the existing GUI will naturally be the editor for configs (both new and existing ones that have been loaded), but I'm thinking there's also going to need to be functionality to safely rename/delete existing configs.

What are your thoughts on which xhtml files are processed in the various scenarios?

1) I'm imagining that an Automated List run should process all files with bk.text_iter(). Because other tools in the same Automated List would not limit themselves to the same files that TagMechanic would single out with Book Browser's bk.selected_iter() anyway. If you need that kind of granularity, use the Full or Minimal GUI.

2) The Full GUI and the Minimal GUI scenarios will use the existing files selected in Book Browser's bk.selected_iter() (like it is for Full GUI now). Mainly because changing that in Full GUI mode would be a large step away from long-standing behavior, and even if I did allow the selection of files directly in Full GUI mode, the Minimal GUI would not have the ability to do anything but pick the config and run. So it's either all text files or Book Browser's bk.selected_iter() for the Minimal GUI. I'm leaning toward the latter for consistency.

Thoughts?

[BeckyEbook]

Ad 1. OK.

Ad 2. Hmm…
I admit that here I really understand the preservation of backward compatibility, however, I think I would change two elements as I did in my fork (#1 (comment in lines 23-32), #2 (lines 30-60)).
What I mean is the case when I want to apply changes to all xhtml files, however, but don't want to select them (I'm always in a hurry), when I can, after all, stand on the "Text" folder and know that it should make me mean "All XHTML files".
Now it doesn't, and I get the disliked message: "No text files selected in Book Browser!".

I believe that whatever decision you make will be fine because just this detail in the code is a subjective matter. The most important thing about this plugin is the very idea, execution, and stable operation, which makes – at least for me – TagMechanic a gem in Sigil.

[DiapDealer]

Thank you for your input. I really appreciate it! I'll keep it all in all mind. I admit that I'm just not crazy about All Files being the default fallback solution when No Files are selected. But that's mainly a personal issue. Because I almost never want to run TagMechanic on all text files in an epub.

I'll try hard to come up with something that can accommodate all of us.

One big concern I have is having three different strategies for the three different scenarios. I would find that confusing. I'll look into creating a preference that would allow a user to opt into (or out of) an All Files default fallback (as opposed to failing completely when no files are selected in Book Browser).

Thanks again!

[Capricorn]

Ah well...I am not a programmer. So some of the discussion is not for me.

I personally like to have "all files" as an option, as I am also always in a hurry, and I like to remove a maximum of crud everywhere. So far that strategy has resulted in good stuff over the years. Maybe one or two books a year that get screwed up a little bit, but that is a price I am prepared to pay to have all the rest go so much faster.
Whatever you end up producing, it is much appreciated.