jEdit

Committed 22171.

"But there seems to be another bug with the dirty flag in your test case:"

1.) Create new file/empty buffer
2.) Enter "enter"
3.) Enter "tab"
4.) Select all text
5.) Enter "a"
6.) Undo all changes
7.) Redo the first change -> dirty flag will not get set!

"This is maybe an already existing bug. I need to check this."
-> Yes, indeed it is. This bug already exits in 4.5.2

"After I got it again, despite the patch, I took a look at the code. Thank
you for detailed comments, they help a lot in such situations. I wonder if
the writer had in mind that this code will also be reached after regular
edits and macros, not only after search & replace. But that's a side note
only." -> yes, he had :-)

Okay, the assumption was incorrect. with the "useMD5forDirtyCalculation"
option set, the "newElement" can be significant for undo.

Attached patch fixes this.

But there seems to be another bug with the dirty flag in your test case.
while redo all changes the dirty flag is not set correctly. This is maybe
an already existing bug. I need to check this.

And finally steps to reproduce:
1. java -ea -jar jedit.jar -noplugins -nosettings
2. check Never mark buffers dirty if contents are unchanged
3. type something
4. create new buffer (untitled-2), this makes the new setting effective
5. change the mode to c
6. type enter (newline and indent)
7. select all (only newline, ok)
8. type anything, say "a", it is thrown silently. If you paste something
instead, you will get a loud assertion break

After I got it again, despite the patch, I took a look at the code. Thank
you for detailed comments, they help a lot in such situations. I wonder if
the writer had in mind that this code will also be reached after regular
edits and macros, not only after search & replace. But that's a side note
only.

The problem must be in the "Never mark buffers dirty if contents are
unchanged" switch (in Saving & Backup section), that I had on only on one
of my machines. The only one that threw the assertion. That switch, if on,
makes the dirty flag clear after any edit that restores the file to its
original state.

Mhh. I'll try to reproduce this one. But I guess this is an consecutive
error of bug 3551910.

It was only once when I got it. I know I made a double paste, while usually
I use "Duplicate lines" shortcut for that. I had several lines in
clipboard. Probably previous activity plays role here. It was not a fresh
instance of jedit, I did about hour of work before getting there. I know
this is of little help, but that's all I can give at the moment. After all
it's only an assertion, so maybe a usual priority of 5 would be enough. The
other s&r ticket contains steps to reproduce.

The failing assertion is:
> /* search for nothing (via regexp) will results just in Insert-Edits.
> * So we won't get here as lastElement will be an Insert, too
> */
> assert newElement != undoClearDirty;
http://jedit.svn.sourceforge.net/viewvc/jedit/jEdit/trunk/org/gjt/sp/jedit/buffer/UndoManager.java?revision=21939&view=markup#l367

Re-reading the comments on assertions including the above, I'm being
tempted to replace all assertions into the 2x2 tests. I know some of
the tests are redundant, but it seems hard to be *sure* of that.

Additionally, if these assertions are based on some conditions of
caller sites, such conditions may be broken by future changes without
knowing the existence of these assertions.

The advantage of assertions seems only little performance gain here
because a branch (returning null) is already there for a similar case.

However, I want to be sure how the assumption in the comment was broken.
The analysis is in progress.