You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Usually in vim, one can't open the same file twice because a swap file is present, and one gets a warning on the second open (ie. the "Another program may be editing the same file" warning). This is not foolproof, but it generally works.
However, this doesn't happen when editing files with vim-gnupg -- it's possible to open the same file multiple times. Makes sense, since the normal version is implemented using swap files, but perhaps there should be some other form of synchronisation.
Not a massive deal for my use case, since I can just add flocking externally, but I'm not sure if this is intentional or an oversight :-)
The text was updated successfully, but these errors were encountered:
Not a massive deal for my use case, since I can just add flocking externally, but I'm not sure if this is intentional or an oversight :-)
It's a side effect of disabling swap files. An interesting possibility might be to use a new buffer for the unencrypted contents and maintain the swapfile on the encrypted buffer.
I'm not sure how feasible that would be nor how much work it would take.
It seems like what's wanted here is for vim to support locking-without-swapfile, or perhaps, swapfile-without-contents.
That smells like a job for a new/distinct vim plugin, which vim-gnupg could then make use of. I'm kind of surprised that doesn't exist already, but I couldn't find such a thing. There is some discussion of adding flock-style locking to vim, which might or might not be viable here...
Usually in vim, one can't open the same file twice because a swap file is present, and one gets a warning on the second open (ie. the "Another program may be editing the same file" warning). This is not foolproof, but it generally works.
However, this doesn't happen when editing files with vim-gnupg -- it's possible to open the same file multiple times. Makes sense, since the normal version is implemented using swap files, but perhaps there should be some other form of synchronisation.
Not a massive deal for my use case, since I can just add flocking externally, but I'm not sure if this is intentional or an oversight :-)
The text was updated successfully, but these errors were encountered: