| Summary: | save doesn't work after redo | ||
|---|---|---|---|
| Product: | [Applications] kate | Reporter: | Jeremy Lainé <jeremy.laine> |
| Component: | part | Assignee: | KWrite Developers <kwrite-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | ||
| Priority: | NOR | ||
| Version: | 2.5 | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Jeremy Lainé
2007-04-02 21:05:23 UTC
Can you reproduce this with plain kate? If so the bug needs to be moved to kate. AFAIK we don't intercept saving or undo/redo from kate, but I might be wrong. nm. A short test shows its in fact kate that is buggy here. Reassigning. Kate save's always, even if redo/undo would flag the file as not modified.... Beside that, can't reproduce... Please reopen this bug! Different behaviour for Kate and KDevelop: Kate always saves, regardless of flag, KDevelop does not save if flag is not present. WARNING: In both cases the result is DATA LOSS if you close the file with the flag not set!!! Steps to reproduce for both Kate and KDevelop: - new file - edit - save - undo - save - redo --> modified flag is NOT shown Next Kate steps: 1) close the file --> the changes are lost! 2) save and close the file --> file correctly saved Next KDevelop steps: 1) close the file --> the changes are lost! 2) save and close the file --> the changes are lost! 3) compile the file --> old version is compiled! KDE 3.5.5 KDevelop 3.4.1 Sorry didn't really pay attention to this. Cristoph, you're saying you can't reproduce this bug? I still can reproduce both problems using KDE 3.5.7. In fact I think there are two problems here: a) kate not setting modified flag after redo and thus not asking wether file should be saved. b) kdevelop doing the same thing (or actually not doing it) and as its file-save-logic depends on the modified flag it doesn't save even if its explicitly asked for. I think that the behaviour of KDevelop is good because when you have a lot of files opened and you compile, saving only modified files speeds-up the operation. The problem is not setting the modified flag. Some notes: - if you undo and redo it works correctly, the problem arises only if you save when you have undone all the steps: if 3 operations are in the undo list, all 3 must be undone, then the file saved and redone all the 3 operations; - if you have 6 operations (sample number) and you undo 3, then save, then undo 3 and save, now redoing 3 removes the modified flag; it remembers the last but one saved position in the undo list Summing up it remembers correctly the last saved position in the undo list, but if you save when the you are at the beginning of the list (that is when you can only redo and no more undo), saving the file does not update the last saved position in the list. I hope this analysis (if it's right) can help you to solve the bug! K, I can reproduce now, the problem seems to be in this code snippet:
void KateDocument::updateModified()
{
if ( ( lastUndoGroupWhenSaved &&
!undoItems.isEmpty() &&
undoItems.last() == lastUndoGroupWhenSaved )
|| ( undoItems.isEmpty() && docWasSavedWhenUndoWasEmpty ) )
{
setModified( false );
kDebug(13020) << k_funcinfo << "setting modified to false!" << endl;
};
}
either the lastUndo.... is wrong or the docWasSa... is wrong..
Either way, this looks not that good, I doubt that works if the undo is limited...
Higher prio This is broken in /trunk, too, and there even more completly.... A complete mess..... Fixed in svn : branches/KDE/3.5/kdelibs/kate/part SVN commit 676516 *** Bug has been marked as fixed ***. |