I think you just described the difference between the Easy Way and the Right Way …

If you select just that character you can see its Unicode in the Info Panel.

I'm betting it's an U+FEFF, a reserved value according to Unicode, and so it was safe for Adobe's engineers to put it to other uses (since it's not allowed as a character code). The U+FEFF code is visible on screen, but since it's usually a very specialized marker for more data, you are usually not allowed to copy it.

If it is U+FEFF, you are not yet done :) Strangely, GREP does not allow you to search for it the usual way, using

— which ought to have worked! It's rather strange because you can find it just fine with regular Find Text, using the notation

A curiosity: this same code is used for XML tags and for Index Markers. You cannot replace XML tags (they simply won't budge), but removing Index Markers works fine.

(Another curiosity, proving the “special status” of this code: the special codes ^I (Text) and ~I (GREP) will find Index Markers but skip other occurrences of U+FEFF.)

Undo? That's what I use if I'm replacing manually and think I made a mistake. Pressing Undo returns the cursor back to the last change position, Redo takes you back back.

Find Previous has never been possible in any version of InDesign. (Okay, couldn't remember so I spend some time on the Web … neither had PageMaker!)

It's a curious omission.

It should occur with every CS4 document … It automatically opens as a Copy because the file format is changed.

This has always been the case with opening older version files.

.. there is no any other language version. It is originally created in InDesign ..

It has been created on Mac OS X 10.5.8 in app version 5.0.4.682 (FS InDesign Japanese — a CS3 version) on Saturday, Oct 24, 2009, 10:14 AM. Per 13 July 2010 it was opened on a Mac OS X 10.5.8 with a Roman (regular) CS4 InDesign.

I've browsed the Scripting Ref but it appears the Roman InDesign simply does not have a command interface to change this. Create a new document and move your text in there.

Regarding vertical positioning: Use a Rule Above, with a color of None and a good distance in Vertical Offset, and switch “Keep In Frame” on to offset a first paragraph on a page. Works every time.

As for hiding a running header, rather than shift-click and deleting it (deprecated, actually) or applying another master page (which personally I prefer, and I take re-applying them for granted), you could use this extremely Dirty Trick. (Hold on to your seat.) In addition to your Rule Above, also define a Rule Below. Set its color to Paper and its thickness to +/- 12 pts — do not opt to Keep it In Frame. Then move it upwards with a negative Vertical Offset to cover the running header.

You might need to apply this style on the occasional left-hand blank page as well, if you start everything on a right hand page. If you have page numbers at the bottom, you can make a specialized “blank page” style, where you use the Rule Above (without Keep In Frame) to hide stuff on the top, and Rule Below to hide the bottom things.

Thanks for the honourable mention, but I do think you're out of luck here …

Ad will find the first number in your story (i.e., one without a dollar sign before it) but GREP cannot discern frames. That is, A (and Z) will not match the first (or last) character per frame (much like GREP cannot 'see' the individual lines per paragraph).

You are also correct in your observation that anchored objects make things even more complicated — I've seen anchors move around and disappear when I tried to manipulate the text around them with GREP.

I think it's safest to remove all dollar signs using the regular Find-and-Change (GREP sometimes has problems with $, and you don't need a specialized GREP search to remove them either) and then just manually page through your document and insert them by hand where needed … :(

w (type double backslashes in this forum ;)) doesn't really match a 'word', but just one 'word character'. According to InDesign, word characters include 0-9, a-z, A-Z, Cyrillic, Greek, and possibly other scripts as well (Hebrew, Arabic, Thai, Chinese and whatnot) and all accented variants of them. It noticeably does not include the common hyphen, so if you might have one in one of your words, you need to adjust your GREP.

The problem you are facing is that GREP is GREEDY by default: it tries to grab as much as possible, but always within the constraints you put in. That's why the seemingly straightforward “w.+~>” will capture anything up to the very last en space. Everything inbetween is matched because the period is 'any character at all', which is what gets repeated — in effect, it scans for the very first word character it can find, then matches everything up to the very last en space.

Fortunately, there is a toggle to make it less greedy: add a question mark after the repeat character. In addition, since the space is not a “word character” either, you need to specify that's valid too.

This ought to work better:

[w ]+?~>

which in plain English translates to “either a word character or a space, repeated as little as possible before encountering an en space”.

I'm a fan of matching as little as possible; in your case, it would match an optional initial space as well as the final en space. That's to be frowned upon, because imagine you want to apply underline instead of bold; then you'd see too much is marked. (I test my GREPs with Underline rather than Bold, so I can see what spaces get picked up.)

This somewhat more complicated GREP will do a neater job, because it only starts at a proper word character (not “word or space”, which picks up the first space) and checks for but does not include the final en space. I also added the hyphen in the repeating OR-set (it's a special character inside an OR set, so it needs escaping to get an 'actual' hyphen).

w[w- ]*?(?=~>)