Undo merges with subsequent changes despite a reasonable period of user inactivity when it shouldn't.

Hi,
I am currently building an IDE using RichTextFX and when i use the method undo , redo it didnt work properly.
If you undo what you write it delete all the text you write normaly it only delete the last word or the last line.
If you don't do any action like copy/paste/cut on the code the undo method will clear all the code area even if u tiped 1000 lines.
Hope u will understand !
Windows 10 x64, coding with NetBeans.
I'm using the RichTextFX FatJar version 0.7

[JordanMartinez]

@eliottizi I'm going to try clarifying what you've written. Is this correct?

1. Add text to the area by manually typing content into it. In other words, don't copy/paste something.
2. Call undo via CTRL + Z and undo your work
   • Expectation: delete the last word on the last line

My guess is that every time you input something via the keyboard, the previous undo is merged with the new change you have done (e.g. added a character). i think if you pause for a bit, it stops this, but I've never fully understood how this part of the code works.

[TomasMikula]

Yes, if subsequent edits "touch" or overlap each other, they are merged. As a consequence (that I haven't realized until now), if you start with an empty document, every edit will be merged into the previous one. Pausing will not help. We might want to provide a more meaningful default behavior. In the meantime, you can invoke area.getUndoManager().preventMerge() manually. A reasonable time to invoke it might be after the user paused typing for a second or two. See e.g. Trigger processing after a period of inactivity for how to do it.

Yes that's it @JordanMartinez !
I will try it @TomasMikula .
Thanks for your answers guys ;)

[JordanMartinez]

@TomasMikula We could quickly implement such an idea via a StateMachine that stores a boolean (true = do not merge changes; false = merge changes when possible) for determining whether to preventMerge or not:

• initial state = true
• user starts typing: state = false; a timer starts
  • if user types before timer ends, timer restarts
• if timer finishes, state = true
• if any other text manipulation occurs (e.g. cut, paste, developer-made function), state = true & timer is cancelled.

However, I see one type of bug that could arise from this:

• Let's say the user is typing some long text.
• Before the timer runs out, the user calls some shortcut that will execute a custom developer-made text-manipulating function.
• Since the state is still true, the new change might be erroneously merged with the user's typed-in-text change. This might be desired in some cases, but we'd need to document this possibility so developers are aware of it.

[JordanMartinez]

Closed by #530.