ReplaceAll InSelection keeps selection...sometimes!

[Alan Kilborn]

In attempting to record a macro to do 3 substitutions on a piece of selected text, I wanted to do it in one regex operation, but I hit a limitation (may go more into this later, because it is somewhat interesting…).

So instead of one operation, I split it into more than one, but when I did that I discovered another something interesting.

Here’s an example:

Problem statement: Replace (in-selection) all foo to FOO. Then, Replace (in-selection) all bar to BAR. Next, put I am onto the front of the selection.

So, the macro (or the series of replacement actions) would take foobar and we’d end up with I am FOOBAR. I am able to achieve this, luckily, but what I discovered makes me wonder if this “general technique” would fail with certain desired text transformation sequences.

So we put “foobar” as text in a N++ tab, select it, and things look like this:

Then we fire up the Replace box. In selection is ticked so we just do a literal Find what of “foo” and a Replace with of “FOO”. We press Replace All and we get:

“bar” -> “BAR” as the next replacement is set up and proceeds similarly, to obtain:

Oh! but wait! What happened to the selection itself? It has now dropped the “BAR” part from the selection!?

Keep on going, how to put "I am " on the front of this (remaining) selection? What I thought of was regex replacing (?-s).+ with the new text. Indeed that works, and the resulting text is:

Notice now that the “selection” has entirely vanished (and remember all replacement ops described above have been with In selection ticked), so…if I had just one more thing I wanted to do to “selected text” via a Replace All, I’d be out of luck.

To add to the inconsistency, I still see In selection ticked in the Replace window, but as I just said, I have no currently selected text:

So, I’m left wondering why these selection changes happened.
In my mind, proper behavior is to operate on selected text, and then keep the bounds of the starting selection as much as is reasonable, after the replacement.
Clearly, if something happens like the replacement operation removes ALL of the initially selected text, there is nothing to keep, and no selection should remain.
But in other cases…

What do others think here? Bug? Feature?

[PeterJones]

@Alan-Kilborn ,

Interesting. My guess is that it’s just an unintended consequence of the way things are done behind the scenes for replace-all-in-selection.

@Scott-Sumner would likely know, given that many of his commits are in the search/replace realm. You might be able to find him at the gitter-based live support room – he might be able to give you more insight.

[Alan Kilborn]

So my final operation from above is somewhat interesting (this is separate from the above discussion about what happens to the selection after in-selection replace-all):

Using a replacement operation with a selection, how would you simply add some text at its beginning (start of selection), and by “add” I mean simply that, add something and keep what’s there.

I did it above by using .+ and replacing with I am and a space.

[BTW, sharp-eyed readers will note that I screwed up my example because I originally said I wanted to end up with I am FOOBAR but somewhere midstream I changed it to I am BAR. Dammit! I really intended replace-with to be I am ${0}. Well, I guess that isn’t super-important to the point I was trying to make, so…]

But anyway, my first thought was to use ^ to match the start of the selected text. Well, that quickly fails because this only works if start-of-selection was at the start of a line, due to the nature of ^.

But that still leaves the question, IS there a good way to match the start-of-selected-text with a regex for this type of replace-in-sel op?

[Alan Kilborn]

And of course, here’s an inconsistency relating to what I was just discussing concerning ^:

^ won’t work with start-of-selection, but \z will work with end-of-selection

See THIS POSTING, where I said:

with an In selection search, we have to be careful in our thinking about \z being strictly an “end-of-file” thing. In this case it is more of an “end-of-selection” thing. :-)

[Ekopalypse]

@Alan-Kilborn

if \z works with selection, maybe \A does work too?

[Alan Kilborn]

@Alan-Kilborn said in ReplaceAll InSelection keeps selection...sometimes!:

And, to bring it all “full circle”, my original thinking was that I could get there in one step. My original statement in this thread:

Problem statement: Replace (in-selection) all foo to FOO. Then, Replace (in-selection) all bar to BAR. Next, put I am onto the front of the selection.

I started here:

find: (^)|(foo)|(bar)
repl: (?1I am)(?2FOO)|(?3BAR)

Which, obviously doesn’t work because of the ^ usage.

[Alan Kilborn]

@Ekopalypse said in ReplaceAll InSelection keeps selection...sometimes!:

if \z works with selection, maybe \A does work too?

A good thought, but no, it doesn’t. :-(

[Alan Kilborn]

BTW, during some of the testing for this, I got into weird situations (one mentioned above) where definitely the In selection checkbox was “out of sync” with how Notepad++ normally handles it.

As another example, I had selected text, and the In selection checkbox was not ticked, but when I did a Find All in Current Document, the Find result window said:

(0 hits in 0 selections of 1 searched)

instead of:

(0 hits in 0 files of 1 searched)

So something funky is up with that.

I remember a recent poster in another thread had said that even though he had selected-text, the In selection box would not “enable” for him so that he could tick it. I tend to take that poster a whole lot more seriously now. :-)