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?:

Caret placement and undo/redo are really Scintilla decisions/actions, aren’t they?

Scintilla keeps undo history, and it does not keep information about the the selection (including anchor and caret positions). Neither does it provide (as far as I can see) any notification that would tell the host program when it is creating an undo step. (Some things, like sequential typing, get combined into a single step, and as far as I know the details are not documented, nor are they guaranteed to be stable or consistent.) Even if the host kept its own history of cursor positions, I can’t imagine a practical way to match that up with Scintilla undo steps.

The only plausible ways I can imagine to do it would be to get Scintilla to support it, or to modify the included copy of Scintilla to support it — unlikely and fraught with peril, respectively.

Alan Kilborn

@Coises said:

Scintilla … does not keep information about the the selection (including anchor and caret positions)

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).

Now, sure, if we’re talking about a Notepad++ function being invoked, e.g., removing empty lines, then Scintilla wouldn’t really have a clue about best post-action caret positioning, and Notepad++ would have to do it, if the person that wrote that command’s code decided it was worth it to explicitly position the caret when done. If not, I’d guess that Scintilla just has some logic to move the caret (best case: only slightly) if the text containing the caret before the op is removed.

(Scintilla)… neither does it provide (as far as I can see) any notification that would tell the host program when it is creating an undo step

The “modified” notification SCN_MODIFIED has information about undo/redo. But still, glancing at this, it probably would be difficult to use to come up with a workable solution to OP’s problem.

would be to get Scintilla to support it…unlikely

I agree, on both points.

Sorry @notdodgeball , I don’t see workarounds to this behavior, or that it will get “fixed” at any time in the future.
However, the only chance it has of being changed is if an official report is put in about it; see the FAQ on this site for how to do that.

guy038

Hello, @notdodgeball, @Coises, @alan-kilborn and All,

@notdodgeball, I think that we could use macros to achieve what you want to !

Here are the two macros which enhance the Undo/Redo actions, as it moves back to the current location, after execution !

        <Macro name="Enhanced UNDO" Ctrl="no" Alt="no" Shift="no" Key="0">
            <Action type="0" message="2172" wParam="0" lParam="0" sParam="See https://community.notepad-plus-plus.org/topic/26403" />
            <Action type="2" message="0" wParam="43008" lParam="0" sParam="IDM_SEARCH_CLEAR_BOOKMARKS" />
            <Action type="2" message="0" wParam="43005" lParam="0" sParam="IDM_SEARCH_TOGGLE_BOOKMARK" />
            <Action type="2" message="0" wParam="42003" lParam="0" sParam="IDM_EDIT_UNDO" />
            <Action type="2" message="0" wParam="43006" lParam="0" sParam="IDM_SEARCH_NEXT_BOOKMARK" />
        </Macro>

And :

        <Macro name="Enhanced REDO" Ctrl="no" Alt="no" Shift="no" Key="0">
            <Action type="0" message="2172" wParam="0" lParam="0" sParam="See https://community.notepad-plus-plus.org/topic/26403" />
            <Action type="2" message="0" wParam="43008" lParam="0" sParam="IDM_SEARCH_CLEAR_BOOKMARKS" />
            <Action type="2" message="0" wParam="43005" lParam="0" sParam="IDM_SEARCH_TOGGLE_BOOKMARK" />
            <Action type="2" message="0" wParam="42004" lParam="0" sParam="IDM_EDIT_REDO" />
            <Action type="2" message="0" wParam="43006" lParam="0" sParam="IDM_SEARCH_NEXT_BOOKMARK" />
        </Macro>

To test them , I followed these steps :

First, I copied the well-known License.txt with the name Notdodge_Test.txt
I switched the Notdodge_Test.txt tab
Then, by using the Ctrl + C and Ctrl + V actions, I duplicated this file, till I got a 500-lines file, about
I moved to line 150, with the Search > Goto... menu command ( Ctrl + G )
Then, I ran, for example, an Edit > Line Operations > Remove Empty Lines operation

=> All the text was naturally compressed

Then, I ran the Enhanced UNDO macro

=> All the empty lines were back again, and you can verify that the current location is back to line 150

But, finally, I chose to keep the suppression of the empty lines.

Thus, I ran the Enhanced REDO macro

=> Again, all the text was compressed and the previous location was back. However, the number of the bookmarked line has changed to line 90, due to the obvious suppression of the empty lines !

REMARK :

As the current file may already contains some bookmarks, I preferred to clear all the bookmarks, at beginning of these macros, to be sure to move back to the exact previous location ;-)

Best Regards,

guy038

Alan Kilborn

@guy038 said:

As the current file may already contains some bookmarks, I preferred to clear all the bookmarks, at beginning of these macros, to be sure to move back to the exact previous location

While the undo/redo technique in your macro is viable, it effectively neutralizes the usefulness of bookmarks for other purposes (it 100% dedicates bookmarks to this undo/redo purpose).
It seems to be a big feature to “kill”, just to have better caret undo/redo positioning.

Perhaps a script that uses a different marker (one not used by Notepad++ itself) would be better than the macro, e.g., here’s a sample “enhanced undo” script (just a demo):

marker_id = 1
editor.markerAdd(editor.lineFromPosition(editor.getCurrentPos()), marker_id)
editor.undo()
editor.gotoLine(editor.markerNext(0, 1 << marker_id))
editor.markerDeleteAll(marker_id)

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.