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!