Fix a few undo-related bugs#4310
Conversation
|
@JakubValtar Can you review? |
|
Reviewing right now. |
|
#4280 is not fixed Other two are fixed, but I find Undo still terribly broken when more tabs are involved. When Undo modifies more tabs, the code in Editor is updated, but they are not marked as modified (orange strip), and when I save without visiting the tabs, changes made by undo are not saved (something to do with SketchCode having both I was also fighting with this with Rename and I temporarily fixed it in some places (JavaBuild, PreprocessingService) by re-reading documents from all tabs instead of using SketchCode's Also when Undo affects more tabs, you can undo only from one of them, others don't have any Undo available. I think Undo needs to be fixed before 3.1. The situation with rewriting text from code is already quite convoluted and maybe it would be better to clean it up instead of adding more complexity by merging this. If you want I can look at it tomorrow. |
|
Hm, so that would delay 3.1 for a week. Are things any worse with Undo than they have been in the past? Or is it just a matter of it being a high priority? |
|
Ok, done. |
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
This PR attempts to resolve #4280, fix #4302 and close #4303.
#4303 was mostly an issue with not considering
Replace Allas a compound edit. I have leftReplaces to be individually undo-able, since technically eachReplacei a distinct operation (unlikeReplace Alls, which all happen at once).I had to modify the
JEditTextAreaa little for #4280, because the replacement happens from within there, and there's noEditorobject accessible (and hence, theEditor's compound edit methods can't be called). TheSyntaxDocumenthas compound edit methods, but they were left blank, and never overridden, so I now have.#4302 was a little tougher to crack, but primarily boiled down to each insert and deletion being considered a separate compound edit, with replacements (i.e., entries in
Insertmode) being modeled as a delete+insert, which kept triggeringendCompoundEdit()and starting a new one. Another issue was that a compound edit ends whenever the text in the Editor is the same before and after a key press, which could happen when the user replace a line likeint k = 4;with `int x = 5;' (several character overlap here, and the set of characters between each overlapping "block" would be undone at a go, and a block could be as small as a single character).@benfry There are changes in here to a few of the methods, and how they are called, but I have tried to keep things as neat as possible. Could you please let me know if these changes are ok, if any modification to how changes have been incorporated need to be made, or if further changes are required? Thanks!