User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 Build Identifier: We attempt to preserve the undo history after saving a file, but still mark the file as unaltered. This is tricky, and leads to at least one condition under which Mousepad is thinks a file is unaltered, but doesn't match what is on disk Open a fresh mousepad instance. Type several words, so that there are multiple levels of undo. Save the document. Now undo once. Notice that the asterisk does not appear in the titlebar. You can also quit Mousepad without a warning. It is worth noting that recent version of Leafpad seem to bypass this problem by simply wiping the undo history after a save. Tempting Reproducible: Always Steps to Reproduce:
Perhaps some kind of hashing algorithm could be used to verify that the undo stack is in the proper state? Get it's height, the memory address of the top element, and the text field (if it will continue to have a text field), and use that to verify the stack?
The easy way out of this is to simply not preserve the unaltered state across an undo. So if you save, undo and redo, the file should be marked as changed (even though it's identical to the file on disk). Although, after looking at the undo implementation, I think the entire thing needs to be redone from scratch to fix bug 2737. http://bugzilla.xfce.org/show_bug.cgi?id=2737 I started doing that, but neither my C knowledge nor GTK knowledge is the very best, so I don't know if I will ever get it to work.
My rewrite of the undo manager in the nick_0_3 branch already fixes all those issues AFAIK.
Hmm, that might be, however, it doesn't work like I'd expect it to, which is a bit of a bummer. That point system is broken usability-wise. Undo should undo a distinct action. Let's say I type this: "the quick brown fox jumps over the quartz pedal" and undo. It deletes the last three words. But if I type this: "the fox jumps over the quartz pedal" and undos it just deletes the last word. As the user is concerned this is totally random, and thus the user can't know what the consequences his undo action will have, which is REALLY not how it should be. Example: When I type three words I want to delete I should be able to hit Ctrl-Z thrice. Now I have to: - hit Ctrl-Z once - look at the screen - check how many words it deleted --- if 1: ------ go to start, and adjust all numbers below to fit the new circumstances (I want to delete 2 words, not 3) --- elseif 2: ------ guess whether another Ctrl-Z will delete more than word or not --------- if i think yes: ------------ delete remaining words manually --------- if i think no: ------------ hit Ctrl-Z ------------ either it's ok now, or ------------ it deleted to many anyways and I have to do Redo and delete the remaining characters manually --- elseif 3: ------ OK, mission accomplished --- elseif > 3: ------ Redo and then delete the words manually. Using the undo facility suddenly became much slower than just caving in and deleting the words manually, which defeats its purpose in my opinion.
Created attachment 3806 attempted fix Will this work? What if we just duplicate what is done in undo_undo()? When saving the file, check whether there's anything in undo_gstr and push it onto the undo stack. The worst that will happen is it will cause an additional undo iteration in the middle of a word instead of the word boundary, if the user saved in the middle of typing a word. I tested this and it appears to provide the expected functionality of marking the file as modified when I undo after a save, and shows the file as un-modified if I then redo again.
This bug can't be reproduced anymore probably because Mousepad now makes use of GtkSourceView which handles Undo/Redo. Please check. If the problem still happens, feel free to re-open this bug.