Bug: Replace all jumps down the file.

[chrestomanci]

I think I have found a small user interface bug.

If you use "Replace" (Ctrl-H), and use the "replace all" button, the view jumps down, presumably to where the last replacement was made. I would expect the view not to move at all, unless I am interactively searching and replacing.

[Aaron]

Thanks for pointing that out. Recently I have been experimenting around with a variety of Text Editors, and it seems a fair number of them do behave as you point out. The current behavior is modeled after Delphi's behavior, and is working as intended.

We will investigate this as a possible change.

Is there a specific reason/workflow where moving the cursor is disruptive? I, personally, don't mind the fact it moves to the last instance (and first instance upon an undo) to show the work has been done.

[Michael Bulgrien]

If there wasn't a status pane at the bottom of Cirrus stating how many occurences had been replaced, then I would agree that moving to the last occurance is beneficial for indicating completion.

Since Cirrus so nicely provides visual feedback regarding the completion of the Replace function in the status pane, I agree with chrestomanci that preserving the current position is preferable.

I have often issued a Find/ReplaceAll to correct "discovered" problems (such as lower-case keywords instead of mixed-case, for example) while I am working on an unrelated item. If the original position is not preserved, then I have to find it again to continue with the task at hand.

[Tim]

We'll definitely consider this change, although the current behavior is partly a result of how the function is implemented (ie, it would be non-trivial to change it).

I'm interested in hearing other opinions as well.

[Jobol]

I'm interested in hearing other opinions as well.

I agree with the poster.

The window should not scroll to another position under any circumstance from it's current position.

Say that I am scrolling the code, and doing some refactoring, and I do a replace. I would really hate it if the pane scrolled down to show me the last replace because honestly I couldn't care less. And to have to scroll back up and find my previous location to continue my refactoring is really annoying.

I see no added value whatsoever in scrolling the window to the last occurrence. Just tell me that you replaced x items and I am a happy camper.

Btw, this is how Notepad++ and Visual Studio's editor work.

[Jobol]

Hi guys,

Any update on this issue yet?

[goldsy]

My vote is to maintain the position.

[chrestomanci]

My vote is to maintain the position.
Could you clarify. Do you mean maintain the satus quo, (i.e the current situation where the view jumps down), or maintain the current view where the view does not move.

[goldsy]

Could you clarify. Do you mean maintain the satus quo, (i.e the current situation where the view jumps down), or maintain the current view where the view does not move.

I agree with your original post that the should not scroll from the position where the replace all was invoked. Sorry for the confusion!

[Michael Bulgrien]

Could you clarify. Do you mean maintain the satus quo, (i.e the current situation where the view jumps down), or maintain the current view where the view does not move.

Neither ;) Jeff used "position" to refer to ones location in the file... not one viewpoint or the other... :)