For a practical use of the Script label panel, see this recent question on the Adobe forum: https://forums.adobe.com/thread/978023?tstart=0

The script is meant to pick up an object labeled “Name_of_the_textframe” (and, presumably, then do something with that object). So, before running the script, the user has to “tell” it on what to work by assigning a label. (But note the last comment on the change for CS5 and newer — apparently you don't need the Script Label panel anymore, or maybe it's even removed in its entirety.)

In my own scripts I've used labels this way, to “tag” items to be processed, such as textframes to do something with; and also to store script-specific information in. I also used it the other way around: during debugging, I sometimes have the script write interesting stuff into a label, so I can see in InDesign itself what the script thought it was doing by clicking an object and checking what's in the Script Label panel.

GREP is “greedy” by default, and it will try to grab as much as it can, while still doing exactly what you asked for. So in your multiple-refs case, it exactly does as told: start with 'ref”, then some unspecified other stuff, then end at (the very last) closing parens.

Fortunately, you can switch this off and tell GREP to use the shortest possible match:

(ref..+?)

(Note that I inserted the — probably — missing backslashes ;) The forum software removes single s, so to get you must type \).

There is no need, by the way, for your construction

[.].+

to force a “literal” full stop. Just add a single backslah before it to make it loose its magic properties.

If you save every section as a separate document, you could use a Book. Moving sections around is then as simple as dragging these around.

Louise, you're almost there. But the $1 and $2 have a crucially important limitation (actually, a feature): they only get “set” to a Found Text value for Find items that are bracketed with round parentheses. That way you can be very selective about what found text you re-use in the Replace With text. Try this Find What:

(d,)(d)

and replace with your own “$1 space $2″.

The first “found text”, to be stored into $1, will be any digit followed by a comma; the second set, $2, will contain the digit after that comma. When replacing, ID writes back digit #1 and comma, then the extra space you inserted into the Replace field, then digit #2. The parentheses themselves do not influence the search text at all.

I am using “d” above to look for any single digit. So this will find any digit-comma-any digit; it doesn't matter if there are more digits before or after each of these.

Using your parentheses correctly to mark the to-be-copied text is important, because suppose you want to find that comma but replace it with a semi-colon. In that case, you would not include the comma inside, but use “(d),(d)” instead and add the semicolon with “$1; $2″.

You can also do other stuff, such as exchange the order of found items — look for “Second name, First Name” and replace with “First name Second name”, for example. And it's even possible to re-use the “found text” immediately in the Find Text field! This is done with a slightly different syntax, you need to use “1″, “2″ (etc.) instead of “$1″, “$2″. Try this one for fun: search for “(bw+) 1″ — it will magically find double words!

Is that square a Wingdings or dingbat? If so, you can include it and the Right Indent code inselfin a Lookbehind, like this:

(?<=~yX ).+$

— I put an 'X' where you should paste the dingbat. Note I added a space after the “X” as well, as per your sample — that way you always need a space between the dingbat and the following text.

If you are using different dingbats, you could use the 'any' wildcard:

(?<=~y. ).+$

as it does roughly the same: after a Right Indent and any character at all, apply your character style up to the end of the paragraph. If possible use the first one, because this one will also pick up a stray space that might have crept in right after that Right Indent, and then the bolding is done on everything after that.

This is for a signature so I can't target the end of the paragraph (because I want to use the same paragraph style for the last paragraph as others).

As it is, my first suggestion will only be applied to Some more text in the exact sequence “Right Indent — Dingbat — Space — Some more text — End of the line”, and it will ignore every paragraph where this does not occur. So it's quite safe, I'd say.

All backslashes disappeared in your post (the forum editor makes single backslashes disappear; you need to type in two \ to get a single — and yes, I actually typed “” to get those two “\”) but on first sight I think the Romanization may not be working because of this bolded part (backslashes inserted where I thought appropriate):

Apply Style: Roman

(?<=[).s]|[d+s]|[;s])([lu]+)( )([.*?)?([lu]+)([. ]?)( )?([lu]+)

First of all you need to re-write it without the + (it's kinda hard to understand exactly what the entire expression does ;) ) because as it stands it would do “nothing” because the '+' is ignored anyway inside a [..] bracketed section. It just adds the '+' to the list of 'allowed' characters. But putting the '+' outside the brackets is no good either, since every test inside a single lookbehind needs to have the same net length, and you cannot use variable lengths at all.

Can you further pin-point the exact point of the expression where it fails? A good way to check what expression does what is disabling all of them but one. All you need to do is insert an invalid command at the very start — having a '*' there is invalid and will effectively kick the entire further expression out of the loop. To visually verify the expression works as expected, add this to the character style: Underline on, 12 pt thick, offset -3 pt, color Full RGB Green. That will highlight the applied style just nice.

It's not possible with GREP, this needs a script.

Unfortunately, the script has to work with the entire contents of the active story — I was foolish enough to test on my current working document (>340 pages) and it took so long to run I decided to kill off InDesign. The reason it has to “see” the entire story is because you cannot access any random paragraph at will; the Document Object Model (which is the foundation on which scripts run) must “process” an entire story before you can check the style of any “next” paragraph.

That said: this script runs correctly on a fairly short story; it will select the paragraph containing the cursor, and then any next paragraphs as long as that's not in the same style as it started with.