Automate list not executing search/replace

[ElMiko]

I'm revising old CSS, and am trying to use the Automate List to replace old css with the new. One such example is replacing:

hr {
	border: 0;
	background-color: #000000;
	height: 4px;
	width: 85%;
	}

with

hr {
	border: 0;
	background-color: #000000;
	height: 4px;
	width: 85%;
	}
hr.hrsep {
	border: 0;
	background-color: #000000;
	height: 1px;
	width: 4em;
	margin-top: 0.75em;
	margin-bottom: 0.75em;
	}

If I do a "Current File" search for the first term, I get the match as desired, but if I try to automate it, it returns no matches (and therefore makes no replacements).

But other similar searches DO work... for example replacing

.calibre {[\s.\w\p{P}]+?
	}

with

.calibre {
	display: block;
	font-family: serif;
	font-size: 1em;
	line-height: 1.1;
	margin-bottom: 0;
	margin-left: 2pt;
	margin-right: 2pt;
	margin-top: 0;
	padding-left: 0;
	padding-right: 0;
	page-break-before: always;
	text-align: justify;
	}
p {
	display: block;
	margin-top: 0;
	margin-bottom: 0;
	margin-left: 0;
	margin-right: 0;
	line-height: 1.15em;
	}

Any ideas?

[KevinH]

The automate function runs specific named saved searches. So please show the exact named source in a screencap from your Saved Searches Editor including all the control fields, and of course the exact find and replace fields as well. Then show the automation log, and finally your automation list itself.

Have you tried using all css or selected CSS files in your controls?

If your control target is "current file", then the wrap control should probably be set as well given starting cursor position in the current file matters if that is determined by something earlier in the automation list.

But depending on your find field value, and because it is really an append you are doing and not a replace (the find target will always exist even after a replace) you may need to worry about an infinite loop.

Have you tried modifying the replace so that it modifies the code the find looks for to eliminate a loop? Or are you not using wrap? If not, how are you positioning the cursor in current file mode before running the automation list? Does your automation list run a saved search group or just a single saved search?

Using "selected css" as the target (or "all css") would probably be better than current file as they always starts each file at the top automatically for sequential named searches.

[KevinH]

And as with any bug report, adding a simplified epub example file, a file including the sample searches (they can be exported in the Saved Search Editor), and your automation list would really help so that others can try to recreate what you are seeing.

FWIW, I never use the "current file" mode for searches in an automate list as current file mode needs proper cursor positioning and wrap mode to work reliably so just running a search manually, and running the saved search directly is probably a better idea and manually watching for the wrap overlap condition to occur. That is why I suggested the "All CSS" or "Selected CSS" mode above.

[ElMiko]

When I'm back at the computer tonight, I'll build a mock up file, and upload it along with the screenshots as well as the ini file for the group of searches and the automated list file.

Is there anything else that I should attach?

[KevinH]

You can also export just selected saved searches using the SavedSearches context pop up menu. There is no need to send an entire ini file.

So epub with css file and a single html file, saved searches you use in automation list exported (as above), and a simplified automation list should be enough.

But as I said, first I would try changing the saved search itself to use Selected CSS mode or All CSS files mode and *NOT* the Current File mode as the current file mode does not keep state (ie it is like the old stateless search) and in automation modes you need to use searches that keep state (which is the whole reason the change to search to keep state was made in the first place) especially when you are appending and not replacing with find and replace.

[ElMiko]

Alright, here goes.

I tried the "All CSS" setting, and it didn't work. In fact, it return NO results unless I ran the automated list in the css file in question. As you can see in image AL_03, when it ran the list in a file other than the css file, despite having selected "All CSS", it ran the list as "All HTML", bizarrely.

The other attached images are:

AL_01: which shows that as a standalone search (i.e. not automated), the "CSS - hr" search does work (in "current file" mode or the key board shortcut for searching within the current file).

AL_02: which is the log for the automated list when it is run with "Current file" selected and the css file open. The same result is displayed if you run it with "All CSS" (or its ilk), but ONLY if you have that file open in the viewing tab. Otherwise, as I said above, it yields NO matches.

A couple of additional notes:

1) You will see that in AL_02, the second-to-last search—"CSS - copyright"—similarly had no matches or replacements. It is like the "CSS - hr" search in that it too will match when the search is run discreetly and in "Current file", but will fail when it's run as part of the automated list.

2) I have tried running the "CSS - hr" search (automated) with the following search term instead:

hr {[\s.\w\p{P}]+?
	}

... similar in structure to some of the other searches in the automated list, but alas it doesn't work in this case either! (although, it does work when run as a discreet search in "current file" mode.)

3) I've attached the ini file (see note #4) for the group of searches in the automated list. Only the first, "manual CSS candidates", is irrelevant to the automation.

4) MobileReads doesn't like ini files, apparently, so I changed it to "CSSReplacements.txt"

Please let me know if I've forgotten something, or some additional info is needed!

[KevinH]

Your replacements file shows that your hr css search was done with the control value AH as target:

14\Name=CSS Replacements/CSS - hr
14\Find="hr {\n\tborder: 0;\n\tbackground-color: #000000;\n\theight: 4px;\n\twidth: 85%;\n\t}"
14\Replace="hr {\n\tborder: 0;\n\tbackground-color: #000000;\n\theight: 4px;\n\twidth: 85%;\n\t}\nhr.hrsep {\n\tborder: 0;\n\tbackground-color: #000000;\n\theight: 1px;\n\twidth: 4em;\n\tmargin-top: 0.75em;\n\tmargin-bottom: 0.75em;\n\t}"
14\Controls=RX WR DN AH

The target set to AH means all html files. The target should have been AC for all css files.

Please edit that search in your Search Editor and edit the Controls field and snap a screen shot of your target. Perhaps that Controls widget is broken somehow? If you select "All CSS" files the AC control should be set in your saved search not the AH.

What appears after double clicking in that control field in the saved search editor and setting the target to All CSS files then clicking outside the controls to save it?

[KevinH]

Furthermore once I edited it to select ALL CSS as the target ("AC") and run your automate list I get the following:

RunSavedSearchReplaceAll CSS Replacements/CSS - hr running
Loaded: CSS - hr
Replacements made: 1
Replacements made: 1

Automation List Completed

As I said earlier. using "Currrent File" searches in an automation list is generally not a good idea unless you are sure you have set the initial cursor position properly (and that may be impossible in a automation list where the search is not done first) and are replacing the find field text (not just appending) so that only one pass is made even with wrap turned on.

[KevinH]

In fact when I use the Fill controls to "fix" your set of controls to use ALL CSS instead of Current File or All HTML, and run it I get the following log file:

RunSavedSearchReplaceAll CSS Replacements/CSS - calibre (body) and p running
Loaded: CSS - calibre (body) and p
Replacements made: 1
Replacements made: 1

RunSavedSearchReplaceAll CSS Replacements/CSS - remove base p running
Loaded: CSS - remove base p
No replacements made
No replacements made

RunSavedSearchReplaceAll CSS Replacements/CSS - remove duplicate p running
Loaded: CSS - remove duplicate p
No replacements made
No replacements made

RunSavedSearchReplaceAll CSS Replacements/CSS - calibre1 (basic para) running
Loaded: CSS - calibre1 (basic para)
Replacements made: 1
Replacements made: 1

RunSavedSearchReplaceAll CSS Replacements/CSS - blockquote running
Loaded: CSS - blockquote
Replacements made: 1
Replacements made: 1

RunSavedSearchReplaceAll CSS Replacements/CSS - none running
Loaded: CSS - none
Replacements made: 1
Replacements made: 1

RunSavedSearchReplaceAll CSS Replacements/CSS - noneX running
Loaded: CSS - noneX
No replacements made
No replacements made

RunSavedSearchReplaceAll CSS Replacements/CSS - noheading running
Loaded: CSS - noheading
Replacements made: 1
Replacements made: 1

RunSavedSearchReplaceAll CSS Replacements/CSS - hindent and hindentX running
Loaded: CSS - hindent and hindentX
Replacements made: 1
Replacements made: 1

RunSavedSearchReplaceAll CSS Replacements/CSS - drop running
Loaded: CSS - drop
No replacements made
No replacements made

RunSavedSearchReplaceAll CSS Replacements/CSS - copyright running
Loaded: CSS - copyright
No replacements made
No replacements made

RunSavedSearchReplaceAll CSS Replacements/CSS - hr running
Loaded: CSS - hr
Replacements made: 1
Replacements made: 1

Automation List Completed

So everything appears to be work as expected. If you only want to run on a single css file instead of all of them then use "Tabbed CSS Files" or "Selected CSS files" as your target and make sure you have selected or opened in a tab the css file you want before running the automate list.

All appears to work.

[KevinH]

And, even if you leave it as "Current File" and after fixing the hr entry to use Current File too, it all seems to work as expected if you have open the styleesheets.css and turn on wrap and position the cursor near the top before launching the automate list.

It gives the following:

...

RunSavedSearchReplaceAll CSS Replacements/CSS - hr running
Loaded: CSS - hr
Replacements made: 1
Replacements made: 1

Automation List Completed

So I can not recreate what you earlier reported even using just Current File mode.

Perhaps the issue is tied to Windows somehow. As on a Mac I can not recreate what you are seeing.

[KevinH]

And fwiw, if you make a single search group to hold your searches, you can launch the entire search group in the search editor without any automation list at all in a single click.

[ElMiko]

Oh my God. Okay. I had no idea what that column even meant. Part of the issue is that the majority of my searches have that column blank because Imported them from v 0.7.2....

This is HUGE. It also explains why it the automated list ended up running on "all HTML" for that last search...

[KevinH]

Yes, when we changed search to keep its state and stop having to "watch for overlap nonsense", it made Saved Searches much more powerful. So we greatly extended the target list of files that a regex search could target again making it more useful for automation and regular usage.

So the number of settings we needed to save became larger when the search target list was expanded, so we added a "controls" field to the saved searches (and added a ui to set it all) to make saving and restoring theses targets/settings shorthand possible.

That way the saved searches fully saved everything a user may have in their find and replace settings.