[Plugin] TagMechanic

[DiapDealer]

The only real problem I've noticed is if one tries to go back to v0.4.x of the plugin after running a 0.5.x version. The old plugin won't start unless you delete the no-longer-valid window-geometry data from the json file by hand (or just start fresh by removing the json and letting it be recreated).

[un_pogaz]

Bug:
When you click on "Copy exisiting attribute string" and then change the target attribute, the text box becomes writable again. Same thing if your change the target Tag.

Feature suggest:
When your choosing the <p> as target Tag, it would be nice if in the output/conversion option you could choose <h1>,<h2> or <h3>. Too often, during conversion (or because the ePub is badly built) <p> tags are used for headings.

Also,
I don't quite understand "New attribute string to insert (entire)": Does it replace the old value? or does it insert a value MORE than the old value?
In any case, personally it didn't work. All the <span> I've processed have become 'naked' (bug?).


EDIT: I hadn't seen the Config button (for the <h1>,<h2>...).
A image of it and the associated window in the main computer would be useful, especially for non-English speakers (visual presentation).
(thanks BeckyEbook)

[BeckyEbook]

Originally Posted by un_pogaz

I don't quite understand "New attribute string to insert (entire)": Does it replace the old value? or does it insert a value MORE than the old value?
In any case, personally it didn't work. All the <span> I've processed have become 'naked' (bug?).

Works. You can add class, id or something else and write "entire" to that field.

Sample:

<h1>Chapter One <span>Friends</span></h1>

Result:

<h1>Chapter One <span class="un_pogaz">Friends</span></h1>

[odamizu]

Originally Posted by un_pogaz

Feature suggest:
When your choosing the <p> as target Tag, it would be nice if in the output/conversion option you could choose <h1>,<h2> or <h3>. Too often, during conversion (or because the ePub is badly built) <p> tags are used for headings.

I had the same request See DiapDealer's instructions on modifying plugin.py file to add more tags: https://www.mobileread.com/forums/sh...58#post3737758

Note that in most recent version 0.5.x the file to modify is utilities.py rather than plugin.py: https://www.mobileread.com/forums/sh...66#post4048666

[un_pogaz]

Originally Posted by BeckyEbook

Works. You can add class, id or something else and write "entire" to that field.

Ahh, just like that, okay.
It's not the intuitive behavior, but I see the use and the possibilities it offers.
Thank you.

On the other hand, I did make a test:

Source

<p class="calibre1" id="chapter1">

New attribute string to insert

class="calibre1" => class="beckyebook" type="text"

Expected:

<p class="beckyebook" type="text" id="chapter1">

Result:

<p class="beckyebook" type="text">

New attribute string replaces all attributes! I don't know if this is the desired behavior, but it can be problematic, as in this example where I wanted to keep the id.

[BeckyEbook]

Originally Posted by un_pogaz

New attribute string replaces all attributes! I don't know if this is the desired behavior, but it can be problematic, as in this example where I wanted to keep the id.

IMHO is OK. Because "entire" requires a complete list all target attributes.

Use:
class="calibre1" => class="beckyebook" type="text" id="chapter1"

[DiapDealer]

Originally Posted by un_pogaz

New attribute string replaces all attributes! I don't know if this is the desired behavior

I can't say whether or not it's the desired behavior for all users. I can only state definitively that it is the intended behavior. The full new list of the element's desired attributes must be specified in the box (hence the option to copy the old ones verbatim). You're not merely replacing he attribute used in the search criteria. That level of granularity is not currently offered by this plugin.

[Binchen]

On my macOs Big Sur 11.5.2 output is done without line breaks so it is a bit tricky to get clear about the amount of changes in each file. Is this only the case for me?

[DiapDealer]

I'll take a look at it.

[DiapDealer]

Originally Posted by Binchen

On my macOs Big Sur 11.5.2 output is done without line breaks so it is a bit tricky to get clear about the amount of changes in each file. Is this only the case for me?

Try v0.5.2 of the plugin (attached to this post) and see if that fixes the issue for you. It works for me. If so, I'll make the v0.5.2 release official.

Thanks.

NOTE: attachment removed as v0.5.2 is now available from the first post of this thread.

[Binchen]

Originally Posted by DiapDealer

Try v0.5.2 of the plugin (attached to this post) and see if that fixes the issue for you. It works for me. If so, I'll make the v0.5.2 release official.

Thanks.

[X] Tried
[X] works fine
[X]

[DiapDealer]

Great! Thanks for the bug report and the testing.

[Binchen]

TagMechanic is my most used plugin. But mostly I use it to do the same things over and over again. Would it be possible to save the settings for each task? So something like Saved Searches?
And as the icing on the cake could then save in the new Automated Lists, that not only the Pluigin TagMechanic is to be called, but also immediately which saved setting I want to execute?
And yes, unfortunately, this also brings with it the vexed question of which files to run TagMechanic on.

You can still dream, can't you?

[DiapDealer]

Originally Posted by Binchen

TagMechanic is my most used plugin. But mostly I use it to do the same things over and over again. Would it be possible to save the settings for each task? So something like Saved Searches?
And as the icing on the cake could then save in the new Automated Lists, that not only the Pluigin TagMechanic is to be called, but also immediately which saved setting I want to execute?
And yes, unfortunately, this also brings with it the vexed question of which files to run TagMechanic on.

You can still dream, can't you?

I can look into a "Saved Searches" features, but as for using them in an automation list: I know of no current way to pass custom parameters from Sigil's interface to a plugin. Thus "pre-selecting" the saved search would always be a gui choice AFTER the plugin has already launched.

Sigil's plugin framework only accepts a very specific (and finite) set of parameters that plugins can then utilize. Unless that changes, I don't really foresee any (easy) way to run the TagMechanic plugin without utilizing the gui to select the run parameters (regardless of whether that's individually or in the aggregate).

The files TagMechanic runs on will continue to be determined solely by which xhtml files are selected in the Book Browser.

@KevinH: if you see this, what do you think about passing an optional parameter to the plugin launcher system that is populated from the parameter field of the automation lists? If feasible, it might be an "easy" way for plugin devs to alter the behavior of their plugins when they're bein run as part of an automation list.

[odamizu]

Originally Posted by DiapDealer

I can look into a "Saved Searches" features ...

A "Saved Searches" feature would be great!

I would also be content if simply the last set of settings were remembered. Right now the last Action type, Tag name, and attribute are remembered, but the value, Change tag to and New attribute are not. I often test my settings on one file before applying them to more files, and it would be great if the last set of settings were remembered so I can just re-apply without having to re-input (and possibly introduce typos in the re-inputting) if the first-run was successful.

(Unless this is already possible and I'm missing something, which is always a possibility with me.) Thank you!