Is there a way to prevent the cursor moving after a undo/redo command?

Coises

@Alan-Kilborn said in Is there a way to prevent the cursor moving after a undo/redo command?:

It keeps some information, because I don’t see Notepad++ itself keeping track of how the caret is moving as I type or as I extend an existing selection (as just two examples).

My wording was ambiguous. I meant that Scintilla does not keep selection information as part of the undo history for a document.

Undo history is associated with the Scintilla document, while selection is associated with the Scintilla control. (Notepad++ uses one Scintilla document for each tab, but swaps those into just two Scintilla controls used for the two edit windows.) Notepad++ does some work to save and restore selections and scroll positions when switching tabs; it doesn’t save and restore multiple stream selections, though (just a rectangular selection or the primary stream selection).

Alan Kilborn

NOTE: this is off-topic to the original discussion point of this tab

@Coises said:

Notepad++ does some work to save and restore selections… when switching tabs; it doesn’t save and restore multiple stream selections, though (just a rectangular selection or the primary stream selection).

I have made a feature request (a veiled bug report?) to change this behavior, see HERE.

notdodgeball

@guy038, @Coises, @alan-kilborn

Thanks to you all for your input. I very rarely use bookmarks so I probably will use guy038’s suggestion, I may even assign the macro to Ctrl+Z/Y directly, although I had trouble in the past messing with “basic” scintilla commands.

I’ll let you all know that I tried to use Multi-select All in place of Replace all but the cursor jumping is also present but in a more inconsistent way. In fact, it’s worse in the sense that it jumps before any undoing. Sometimes the screens moves to accommodate all instances of the matched word and that’s nice, and sometimes it can’t do that, but tries anyway, making it worse.

I also tried the plugin Location Navigate, it gets the job done and it’s great in very large files.

Anyway, I will open an issue, but as much as it bothers me, it seems I am in the minority and most users don’t care. Not only that, as Coises explained, it’s a simple request that stumbles upon a deep behavior also involving the Scintilla component.

Alan Kilborn

@notdodgeball

Please post back here after using @guy038 's technique for a period of time; I’d like to know how well that goes for you (or not)!

notdodgeball

Already yesterday I assigned the undo/redo shortcuts with the macros and it worked out great.

There is a part of me with minor disgust knowing that behind every little use of Ctrl+Z and Ctrl+Y there is a full macro going on, but that’s on me.

There is also the commands Alt+Backspace and Ctrl+Shift+Z in case I want the old behaviors.

I won’t bother with the github issue, there is already 2.5k of them. If it is God’s will people will wake up and realize that unwanted cursor movement is a sin and should be stopped but until then I’ll stand alone in the path of truth with my macros.

Alan Kilborn

@notdodgeball said in Is there a way to prevent the cursor moving after a undo/redo command?:

I won’t bother with the github issue… If it is God’s will people will wake up and realize that unwanted cursor movement is a sin and should be stopped…

Or, you’re just lazy.
Things don’t improve unless people put in the effort.
I don’t believe God is going to help with this.

I’ve put in the issue, HERE.

notdodgeball

@Alan-Kilborn, your UndoEnhanced.py script leave the current line with a different background when using a dark theme. Not sure if it’s related to one of the commands or is simply a bug.

After using the macros for some more time, I came to the realization that the problem also manifests when the screen is in a different position from that of the cursor, if fact, the cursor is not what it matters. It only may seem it does when it’s visible in the screen (which is most of the time), otherwise jumping to it’s position is not the solution.

So I made a simple python script and assigned to the Ctrl+Z combo

top_line = editor.getFirstVisibleLine()
editor.undo() #redo
editor.setFirstVisibleLine(top_line)

Actually, I think the logic to be used to implement this featured can be (if possible) exactly like this .

PeterJones

@notdodgeball said in Is there a way to prevent the cursor moving after a undo/redo command?:

leave the current line with a different background when using a dark theme.

This looks like your dark mode theme is out of date, without defining a style that Alan’s script is using.

The details of the problem, along with a possible solution, are described in Config Files Need Updating, Too. (The tedious alternative to my script is described in the User Manual… but since you’re already using PythonScript, you’d be better served running my script to update your theme.)

Alan Kilborn

@notdodgeball said:

Alan-Kilborn, your UndoEnhanced.py script leave the current line with a different background when using a dark theme. Not sure if it’s related to one of the commands or is simply a bug.

@PeterJones said:

This looks like your dark mode theme is out of date, without defining a style that Alan’s script is using.

Well, the script isn’t using a style per se, but it is using a marker that needs no visual component. Thus I didn’t bother to define all of the marker attributes. Probably in this case the marker defaults to coloring the entire line. As I tried the script in “light mode” with no ill effects, I didn’t write any additional code.

Alan Kilborn

@notdodgeball said:

After using the macros for some more time, I came to the realization that the problem also manifests when the screen is in a different position from that of the cursor, in fact, the cursor is not what matters. It only may seem it does when it’s visible in the screen (which is most of the time), otherwise jumping to it’s position is not the solution.

So I made a simple python script

top_line = editor.getFirstVisibleLine()
editor.undo() #redo
editor.setFirstVisibleLine(top_line)

I really don’t see how that is going to be a workaround that always works, either. It’s likely going to be situation-dependent, I’m afraid.

The virtue of the “bookmark” workaround is that bookmarks seem to stay set “around” where they were first set, even when the original line of the bookmark is removed.