"SudoWrite <file>" reverts buffer contents

[blueyed]

Test case:

1. echo 1 > 1
2. vi 1
3. `r2`

The buffer name is changed to "2", but the buffer's contents is back at "1". :e will update it to "2".

[chrisbra]

On Tue, March 12, 2013 16:24, Daniel Hahler wrote:

Test case:

1. echo 1 > 1
2. vi 1
3. `r2`

The buffer name is changed to "2", but the buffer's contents is back at
"1". :e will update it to "2".

I am afraid I don't see this. I did this:

echo 1 > /tmp/1
vim -u NONE -N -c ':ru! plugin/SudoEdit.vim|:exe ":norm! r2"' /tmp/1

Issuing :SudoWrite 1 successfully writes the file.

regards,
Christian

[blueyed]

@chrisbra
Please re-open.

The problem is related to writing to a new file, and undofile has to be enabled.

Then file is 1 here, although I did SudoWrite 2:

let file=substitute(expand("%"), '^sudo:', '', '')

And the following caused the original file to be edited:

exe "e!" file

TEST CASE:

mkdir /tmp/test
cd /tmp/test
echo 1 > 1
vim -u NONE -N -c 'set rtp+=~/.vim/bundle/sudoedit | ru! plugin/SudoEdit.vim | set undofile | exe "norm! r2" | SudoWrite 2' 1

Using this test case, another error appears: "Can't create undofile in current directory, skipping writing undofiles!". I guess this gets thrown, because it is assumed that the undofile would not be writable?
This should probably just try to write it, but then handle any error from wundo.

[chrisbra]

So the problem is, the wrong undofile is written? Current head 9b2f71c should fix this.

[blueyed]

So the problem is, the wrong undofile is written

No, the problem is/was the :e oldfilename.

It appears to be fixed now, given the last two commits (including e6daefd).

Thanks!