Bug 143754

Summary: save doesn't work after redo
Product: [Applications] kate Reporter: Jeremy LainĂ© <jeremy.laine>
Component: partAssignee: 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:

Description Jeremy Lainé 2007-04-02 21:05:23 UTC
Version:           3.4.0 (using KDE KDE 3.5.5)
Installed from:    Debian testing/unstable Packages
OS:                Linux

When editing a file, the "save" operation doesn't work after a redo.

To reproduce:
1/ open a source file
2/ make a change, save file, compile
3/ go to Edit -> Undo in the menu, save file, compile
4/ go to Edit -> Redo in the menu, save file, compile

Result:
The file does not get saved, and "compile" doesn't trigger a recompile of the file.

Expected:
The file actually gets saved to disk, and "compile" recompiles the modified file.

Notes:
I get the same results regardless of whether the keyboard shortcuts or the the menu entries are used for Undo/Redo/Save.
Comment 1 Andreas Pakulat 2007-04-02 21:20:20 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.
Comment 2 Andreas Pakulat 2007-04-02 21:25:44 UTC
nm. A short test shows its in fact kate that is buggy here. Reassigning.
Comment 3 Christoph Cullmann 2007-05-28 21:23:57 UTC
Kate save's always, even if redo/undo would flag the file as not modified....
Beside that, can't reproduce...
Comment 4 Alessandro Garberi 2007-05-29 17:33:21 UTC
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
Comment 5 Andreas Pakulat 2007-05-29 17:59:57 UTC
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.
Comment 6 Alessandro Garberi 2007-05-29 21:36:20 UTC
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!
Comment 7 Christoph Cullmann 2007-06-03 14:10:50 UTC
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...
Comment 8 Christoph Cullmann 2007-06-03 14:25:03 UTC
Higher prio
This is broken in /trunk, too, and there even more completly....
A complete mess.....
Comment 9 Guillermo Antonio Amaral Bastidas 2007-06-17 03:25:18 UTC
Fixed in svn : branches/KDE/3.5/kdelibs/kate/part

SVN commit 676516
Comment 10 Stefan Monov 2007-09-12 11:02:15 UTC
*** Bug has been marked as fixed ***.