On Fri, Apr 16, 2010 at 10:53:34PM +0200, Lech Lorens wrote: > On 16-Apr-2010 Christian Brabandt <[email protected]> wrote: > > Hi James! > > > > On Fr, 16 Apr 2010, James Vega wrote: > > > > > On Fri, Apr 16, 2010 at 11:28 AM, Marvin Renich <[email protected]> wrote: > > > > * Christian Brabandt <[email protected]> [100416 08:35]: > > > >> This has come up on the vim_use mailinglist. The problem seems to be > > > >> that after recovery of a swap buffer, the file should be modified so > > > >> you > > > >> are not loosing your changes after e.g. accidently hitting ZZ > > > >> > > > > Shouldn't this set curbuf->b_changed based on the "modified" setting > > > > from the swap file, so that if you "recover" a file that was not > > > > modified, you don't set the modified flag? > > > > > > I'd think that any time you recover from a swap file, the buffer should > > > be considered "modified". The modified flag indicates that the buffer > > > is different than the on-disk file with the same name. Whether or not > > > the buffer was modified at the time that the swap file was last updated > > > has no bearing on whether the content recovered from the swap file > > > matches the current contents of the file that was being edited. That's > > > up to the user to diagnose and decide what steps to take. > > > > That would be my understanding as well. > > Correct me if I am wrong, but I understand that the current behaviour is > that if you recover a file it does not get the "modified" attribute. As > a result if you press ZZ, you exit Vim without saving the recovered > contents.
That's a very good point. Since the swap file isn't automatically deleted after a recovery, you can always re-recover if you ZZ/:x when you intended to :w. Given that perspective, I retract my suggestion that 'modified' is set. > IOW, I personally prefer the current behaviour. Still, I believe that > there might be a somewhat more complicated solution which would satisfy > both needs. IMO, that way would be performing automatic diffing of the recovered buffer with the on-disk file. If anything short of that is done, then the current behavior should be maintained. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[email protected]>
signature.asc
Description: Digital signature
