I'm using a grep search to change double spaces to singles, so the find grep string is " +" (that's two spacebars). And the change string is one spacebar. Works fine and, no, I don't want to use \s because it grabs other chunks of whitespace that should be left alone.

The problem is that I want to run this search on the text selected by the user. And then run another find/change after that.

But this particular find/change alters the range of the selected text. You would expect it to shorten the selection by the number of extra spaces that it removes, but it seems to be shortening it by more than that..

It's baffling because other grep find/change operations seem to honor the original selection. For example, I'm searching for "^\s+" and replacing with "" to eliminate blank paragraphs and spaces at the beginning of paragraphs. It reduces the length of the selection only by the number of spaces it removes. Similarly, I can use an ordinary text find/change to replace double spaces with single spaces, and the selection adjusts properly. But that find change has to be run in a loop, which seems to take a lot longer.

I noticed this while writing a script. but the behavior is the same in user interface.

I don't think I'm seeing what you see, or I don't understand the description. My selections still cover the same selections, less any deleted spaces using your query (provided I do a Change All), but you might want to try Find: (?<=\x{0020})\x{0020}+ and Change: "" instead. (That's null, or blank)

Start with a block of text containing more than one set of multiple spacebands. This poorly typed paragraph will do nicely. If you look closely you'll see that there are extra spaces between each word.

Select all text in the frame. Then use this grep search on the selection, changing to nothing:

(?<=\x{0020})\x{0020}+

The result I get is that all the extra spaces are stripped out but the selection has shortened so that the whole story is no longer selected. As I said, I'm using this grep search in a script, so the next steps of the script sometimes fail because of the change in the amount of selected text. But the problem occurs in the nonscripted interface as well.

It doesn't seem to happen if the original selection is something less than the whole story. So it's some combination of selecting whole story and then searching the selection. I think there also has to be more than one "hit" in the selection.

My immediate idea is to simply run this search on the entire story, regardless of what the user has actually selected. Can't imagine that being a problem unless someone wants to publish examples of bad typing. Still, it's curious.

It happens in your sample text here, too, now, but so far ONLY when the selection includes the last character of the last paragraph of the story that conatins text. It happens even if there are empty paragrapgs following.

Not sure if that's helpful, but I think it probably means there's some sort of bug at work.

Yes, that's actually how this discussion started. Peter suggested \x{0020} which made sense to me because its more readable than " ". But the problem seems to be the same.

My first idea for a workaround was a flop. Even when the search targets the whole story, the selection shortens up if it includes the last character of the last paragraph. So now I'm thinking that I have to check to see if the last character of the selected text is the same as last character of the parentStory. If so, I'll restore the selection after the extra spaces have been wrung out.