I'm playing around with regular expressions (for the first time; yes, I'm late to the game) in FM2019, and I'd like to create a library of commonly useful regex search/replace strings for my colleagues to use. To make it convenient, I'd thought of putting a selection of these items on a reference page in our basic chapter template, so it would always be just View>Reference Pages away, or perhaps including a separate regex list as part of our book template... but I'd like to make it even more accessible: Is there any way to make saved searches accessible directly in the Find/Change dialogue?
I know Find/Change saves a history of recent strings as a drop-down list in both the Find and Change fields; is there any way to "seed" those lists with predetermined strings (or some other way I haven't thought of to save searches)?
This is a nice-to-have, rather than urgent, need... but it sure would be nice to have. Any insights would be, by me, greatly appreciated!
You may have a look into the maker.ini file in %appdata%\Adobe\FrameMaker\15 (or 16) directory. The list of used find/replace strings however can not be long. The limit seems to be 8 or something like that.
Is there any way to make saved searches accessible directly in the Find/Change dialogue?
This is a such a sensitive subject for me, and I've tried communicating to this to the FrameMaker team—both in person as well as through Tracker (case was closed but the issue was not addressed: https://tracker.adobe.com/#/view/FRMAKER-3589).
InDesign (Adobe's other page layout application) allows you to create and save as many custom REGEX queries as you like (called GREP in InDesign, but it's the same feature), and they are available in the Query dropdown menu in Find/Change.
In addition, InDesign has a REGEX menu that you can use to quickly develop basic queries—great for a new user who is just getting up and running.
As you will see in the Tracker link, Stefan (EDIT: seems to) think
s that having the last 10 queries visible in the recent query is sufficient. I disagree because it may take me a few tries to fine tune the REGEX and by the time I do, a few of my working queries have dropped off the bottom of the list. Also, after a crash, the list will disappear entirely. Finally, InDesign saves both the Find and Change fields in a saved query—in Fm, if a recent query is still in both lists, you have to manually match them up.
My workflow: I work through a new query in InDesign, and then save working queries in Word and copy paste the ones that drop off back into FrameMaker. It's a silly workflow, and one that can be addressed with an update to a future version on FrameMaker.
Please consider logging a new feature request on Tracker: https://tracker.adobe.com/#/home and posting a link to it here. I will certainly vote for it.
Barb, the support of Regex in ID is overwhelming!
I for my part use RegexBuddy to develop regular expressions. A great disadvantage in FM are the very limited expressions in the replacement.
And yes, I also have a sidekick document with the regexes I need often, from which I copy and paste into FM...
Spinning this a little bit further ...
To avoid to much programming (repeat all the functions of the Find/Replace dialgoue) i can imagine controlling the F/R dialogue from outside of FM by an AutoHotkey script sending keystrokes. I had developed an application with this method some time ago.
The UI could look like this:
My intended work flow is this:
Save a set of settings
Use a set of settings
RegexBuddy looks great, but I'm working in a corporate environment with a pretty locked-down IT ecosystem. My group had to fight hard to even get FM and Acrobat (which were not on the approved software list when we adopted them); small 3rd-party apps are just impractical for us.
Thanks (to all of you) for the responses!
"Stefan thinks that having the last 10 queries visible in the recent query is sufficient. I disagree because it may take me a few tries to fine tune the REGEX and by the time I do, a few of my working queries have dropped off the bottom of the list."
Not only that, but what I really want to do is create pretested regex (regexes? regexs?) that the rest of my workgroup can just use, so my colleagues don't have to reinvent or fine tune them. There are a number of predictable ways our input copy can be "wrong" that regex can address (e.g., dates not in our standard format, decimal numbers less than 1 without leading zeros, multiple nonstandard forms of the same unit symbol). My intention is to become the inhouse regex guru, so my fellow editors don't have to. Mind you, they'll benefit if they learn to use regex on the fly... but no need to keep writing and testing the same searches over and over.
A place to stash them in text -- on a Reference Page or a separate "sidekick documnent" (I love that nomenclature, Klaus!) -- will work fine; I was just hoping to make them more directly available.
Huh? Where am I supposed to have written this? Not on this ticket and probably also nowhere else.
Of course, it obviously makes sense to limit the number of stored entries for both usability and performance reasons. Having hundreds of entries after a while would also not make sense. If it would be up to me, I would let the user define the number of strings entries (along with a high internal maximum).
Back in 2016 or 2017 when the "Find/Change History" feature was implemented, the reason to not implement "FindChange History Pairing" as well, was this one: For Find/Change there are "many to many" relations between find and change strings. I.e. the user may have searched a string multiple times and replaced with no or one or more strings. The same applies for change strings. Or the user might search for a cross-reference of a specific format and change to some text. This makes it more complicated as it might look like first.
The pairing of Find/Change as well is for sure a nice to have (and still on my wish list), but while it might look like a small thing, it's quite a big project due to the powerful Find/Change combinations FrameMaker gives.
The key distinction here is between Find/Change history (whether paired or not) and a durable list of saved, named Find/Change strings: The former is a wonderful tool, but it doesn't replace the ability to save and reuse common editorial tasks.
Imagine if the Paragraph Designer "remembered" the most recently used 8 or 10 sets of paragraph settings, but there was no way to create a catalog of paragraph tags? It seems to me the recent trend in FM has been to create more types of named, modular settings for reuse; that's what I have in mind here.
"For Find/Change there are 'many to many' relations between find and change strings. I.e. the user may have searched a string multiple times and replaced with no or one or more strings."
...I'm admittedly a regex newbie, but it seems to me this is far less of a problem with regex than with regular string searches: One of the things that's got me excited about regex is the ability to accommodate multiple possibilities (for both find and replace) within a single search, specifically so I don't have to run many-to-many Find/Change pairs to achieve a conceptually singular outcome (such as, for instance, regularizing numerous variant notations for temperature). In any case, while I see this would be a big challenge for pairing dynamic search histories, each named, saved search pair would, by definition, have a one-to-one relationship between search terms and replacement, whether it was a regex or a "flat" string.
I don't mean to be wading into a controversy, here; it's just that as I began to learn regex, one of my first thoughts was about how to make these tools available to my coworkers in the simplest, most available way.
You are correct, Stefan.
I inferred that you think the recent query list is sufficient both from your response on that thread ("Actually, we have introduced this in FM 2017") and the prompt closing of the case ("Fixed") without acknowledging that we were talking about two different features. Please accept my apology.
As previously stated on this thread, this is a very sensitive topic for me because implementing it will be such a huge time saver for those of us who rely on multiple queries for document clean-up. Saved seconds become saved weekends for those of us who lay out long documents alone.
Voted! (And thank you, DauphinB.)