I'm using SE17, but I think this behavior has been here for a while. I suppose it might not be considered a bug, but it's mighty peculiar.
When you do a search and replace inside a block selection, if the length of the search and replace strings aren't the same, the results are not what I expect. I have some window captures attached. cat.png is my original file with the selection highlighted.
In the first example I replaced the word cat with a dot. I expected the five selected columns of cat to be replaced with periods. Instead it appears that as the length of the lines shank the cats to the right got pulled into the selection and replaced with dots.
In the second example I started with the same text and selection. I replaced cat with elephant. Again I would have expected the five selected columns of cat to be replaced with elephant, but instead the cats got pushed to the right by the elephants and so didn't get converted.
I guess if I were clicking on replace instead of replace all I might expect this sort of incremental behavior, but my expectation is that everything that is selected at the time I clicked on the replace all button would be considered and nothing more.
I've seen this same behavior on other types of selection as well. For example when I wanted to reformat a C routine which had been compressed into a single line by selecting the line and then replacing every semicolon with a semicolon followed by a carriage return, I couldn't do it. I had to copy the line to a temporary file by itself and do the replacement on the whole buffer, then copy it back.
Has anyone else seen this behavior? Do you know of a way to make SE do the right thing and honor the original selection?
