Bug? One newline - 2 undos to revoke...
Is there a possibility to fix the one newline - two undos bug?
Steps to reproduce:
- Create a new file
- Type tab, then aaa
- Press enter. As expected, the cursor goes to new line, indented with one tab.
- Now comes the tricky part: 2 undos are needed to remove the newly created line:
1st undo deletes everything on the line and moves the cursor to the first column.
2nd undo actually deletes the line and moves the cursor back to the initial line.
Two new lines need 4 undos, three 6 undos, etc.
Do - press enter to go to new line, automatically indented.
Undo - go back to the initial cursor position.
This bug was present from the very early versions onf NPP.
Actually I do have a different behavior.
It undos until last savepoint. So it looks like it could be a plugin which interferes
or a particular settings which causes this.
Can you post the debug-info? And do you know about special settings you did?
Maybe you wanna download a zipped npp version from homepage a redo the test?
I don’t think that “savepoint” has anything to do with the OPs problem. The OP is talking about “n” operations needing “m” undos (m > n). Or maybe it is me doing the misunderstanding?
I don’t know that I’d call it a “bug” but I do see your point. Undo in Notepad++/Scintilla seems to work “differently” from other editors I’ve used – read that “differently” as “often annoyingly”. For instance, if I type a long sentence (multiple words) and then invoke Undo, it deletes the whole sentence. Arguably, I’d like it to remove one word at a time, back to the start of the sentence. Or if I type aaabbbccc but move the caret after aaa but then put it back and add the bbbccc part, Undo maybe should first delete the bbbccc part and then a second Undo would delete the aaa. Some editors maintain caret movement as part of the Undo history; Notepad++ does not.
I’ve learned to live with the somewhat quirky Undo behavior. I don’t see a solution or workaround to help you.
To elaborate a bit.
1st thing Notepad++ uses Scintilla “as is”. Some Notepad++ issues are Scintilla issues and can be reported to its maintainers.
One option is to try to reproduce the behavior with SciTE. If it reproduces report it to Scintilla.
Scintilla pretty much manages it automatically. The key events are insertion and deletion of text into document.
Scintilla try to coalesce these events quite aggressively. Basically every insertion that follows a previous insertion will need a single UNDO. Deletions are a bit trickier but follow the same principal. Unfortunately this mechanism ignores caret movements between insertions and does not respect “words” which leads to @Scott-Sumner observation about not being able to undo single words which I agree that would be better.
UNDO engine can also be forced to collect multiple events to a single UNDO ACTION for special things like “search and replace all” but it is only used in a few selective places.
The auto indent feature seems to break the coalescing, maybe by mistake. It probably adds a newline and then add the indentation before the newline so text insertions are not sequential.
If you disable auto indent you will see that you can type multiple lines and then UNDO all of them with a single UNDO. Which is awful in my opinion.
So a true fix is unlikely since it will require UNDO engine overhaul. And the current situation is better than the no indent situation.
From the quick test I’ve done it looks like the caret position seems to be the indicator what needs to be undone.
Example - I have file which contains only the word test.
Press as often enter as you want and type text as you want once you press ctrl+z it will
undo everything that was added newly meaning only word left is left in file.
Now do the same but move the caret to a position above some text and type again some chars
then it will undo the last added chars after caret move and next undo will delete everything else.
(except the word test).
I need to check the code to understand what is going on.
From npp points of view under the following situation an undo action is done
- executing a macro
- sort lines lexicographic ascending
- sort lines lexicographic descending
- sort lines integer ascending
- sort lines integer descending
- sort lines decimalcomma ascending
- sort lines decimalcomma descending
- sort lines decimaldot ascending
- sort lines decimaldot descending
- remove empty lines
- remove empty lines with blank
- trim trailing spaces
- trim leading spaces
- trim both
- eol to space
- remove unnecessary blank and eol
- a replace all (find dialog)
- converting whitespace to tab (or reverse)
- cutting marked lines
- deleting marked lines
- pasting to marked lines
- doing a block comment
- doing a stream comment
- undoing a stream comment
which means the action we are talking is handled by scintilla directly.
Let’s see what this reveals.
When Notepad++ sends explicit
start undo actionto Scintlla, Scintilla still collects the undo operations by itself the same way it always does but the coalescing logic is overridden to force everything to coalesce until Notepad++ explicitly sends
end undo action.
As a result a single UNDO (Ctrl-Z) will undo all changes from ‘start action’ start to ‘end action’.
While I agree that the need for double UNDO after ENTER is annoying the bigger problem is the aggressiveness of coalescing words and lines into single action. As I said before if we just fix this problem then UNDO will delete the entire last paragraph.
1st priority is to tune down the aggressiveness of coalescing.
- It should not coalesce past caret movements.
- It should not coalesce across EOL. Kind of tricky to do it right since we do want at the end that EOL+ auto indentation will be a single UNDO action.
Only after the UNDO is less aggressive the auto-indentation which is the core of this problem should be fixed.
And again all of this is mostly Scintilla work. Notepad++ may try hack things with dummy actions that will serve as UNDO barriers but it is not the right way to do it.
I have absolute no idea how I could miss your post.
Checked even the notifications and still don’t see that you
replied on the original post. Seems there is a race condition if
two reply at nearly the same time.
I agree to what you post.