GNOME Bugzilla – Bug 327432
app-editors/bluefish does not ask to save after "Undo"
Last modified: 2009-06-11 09:54:43 UTC
Please describe the problem: Got this report on gentoo-bugzilla (I'm the maintainer of the gentoo bluefish package): >1. Edit a document in bluefish (app-editors/bluefish-1.0), and then save it. >2. Undo some changes >3. Close the document or program. >Bluefish will close without asking if you want to save the altered document. >Instead, Bluefish should display the "Do you want to save?" dialog box. I can confirm this bug with bluefish 1.0.4. Original bug URL: https://bugs.gentoo.org/show_bug.cgi?id=119246 Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
What GTK and GNOME versions are you using when you see this behavior? Can you recompile with debugging output enabled, pass --enable-debugging-output to ./configure, run bluefish in a terminal redirecting the output to a file, reproduce the behavior, and e-mail the file (bzipped) directly to me. I cannot reproduce this bug on FC4 with GTK 2.6.10 or Ubuntu 5.10 with GTK 2.8.6. I suspect it requires a specific version(s) of GTK to reproduce.
I can reproduce this with CVS HEAD: - Open a file - Type <space><space> - Save - Undo (thinks it's modified) - Undo (thinks it's unmodified)
I can confirm this behaviour with stable too. IMO this is related to the undo/redo queue and setting, if a document was modified. Doing Undo or Redo should always lead to set a doc modified, never set it back to unmodified.
Created attachment 57990 [details] [review] proposed patch The attached patch contains the quick-fix for the issue. The Undo/Redo queue now always sets the document to modified. Opinions?
the behavior that Alastair mentions in #2 is correct in the situation that there would be no 'save'. So a function should be added to the undo/redo code that walks the tree of undo/redo actions, and changes any items that have the 'unmodified' boolean set. This function should then make the last undo/redo action have the unmodified boolean set. I haven't looked at the code, but I remember there is somewhere a boolean that makes the document 'unmodified' after a certain undo action.
(In reply to comment #5) > the behavior that Alastair mentions in #2 is correct in the situation that > there would be no 'save'. No it isn't. The file has been modified since last saving, so should require another save. Consider a more concrete example: open a file foo.php containing <?php echo "foo"; ?> now add echo "bar"; to it and save. the script will now print out 'foobar' Now I don't want it to say bar any more, so I undo the change and close. The file closes, but but will still print 'foobar', and not the 'foo' that I wanted
****in the situation that there would be no 'save'.****
doh
> the behavior that Alastair mentions in #2 is correct in the situation that > there would be no 'save'. A commonly used behaviour is, that only after a save (or load), a document is set to "unmodified". Every step done after saving or loading a document is mentioned to be a change and only the next save can set it to unmodified. It may be, that this behaviour is related to a special kind of backing up the currently opened files. You can found it in e.g. openoffice.org.
On the other hand: Using your idea of walking through the tree adjusting unmodified setting, it may be possible to add a function: "Undo every change made since last save". But I'm not sure about the helpfulness of such a function (close without saving and reopen does the same).
perhaps I was not clear: I did not want to walk the tree of undo/redo items and activate them, I just wanted to unset the item that has the 'document was previously unmodified' boolean set, and set the 'document was previously unmodified' on the first item *after* the save again. the behavior you mention in #9 is far from ideal in my opinion. You type a space by accident, you press undo, and when you want to close bluefish it tells you that there are modified documents... I kind of like to keep the code that bluefish knows which state was saved on disk (but I agree this bug should be fixed).
> perhaps I was not clear: I did not want to walk the tree of undo/redo items and > activate them, I just wanted to unset the item that has the 'document was > previously unmodified' boolean set, and set the 'document was previously > unmodified' on the first item *after* the save again. [..] That is, how I understaood your comment. > [..] the behavior you mention in #9 is far from ideal in my opinion [..] Yes, there you may be right. > [..] (but I agree this bug should be fixed). It _must_ be fixed (I will also have to address this bug to the Debian BTS). This bug leads to data loss, which is a critical issue. I'm adjusting the severity and priority now, to mention this fact. If nobody is faster, I will have a closer look at this bug in the evening.
Jim added a possible solution. http://cvs.sourceforge.net/viewcvs.py/bluefish/bluefish-gtk2/src/undo_redo.c?r1=1.9.2.1&r2=1.9.2.2&only_with_tag=bluefish_1_0 http://cvs.sourceforge.net/viewcvs.py/bluefish/bluefish-gtk2/src/undo_redo.h?r1=1.4.2.1&r2=1.4.2.2&only_with_tag=bluefish_1_0 http://cvs.sourceforge.net/viewcvs.py/bluefish/bluefish-gtk2/src/document.c?r1=1.324.2.15&r2=1.324.2.16&only_with_tag=bluefish_1_0 Further investigation will be taken after 1.0.5 release. So I do not close the bug, but set severity and priority back to normal. Target milestone is set to 1.0.6. The critical part of this bug has been resolved for 1.0.5.
Sorry. Severity should stay at critical, but priority is decreased. Patch is marked rejected.
*** Bug 331113 has been marked as a duplicate of this bug. ***
Jim fix seems to have solved the problem. Closing.