Is there a way to get MacVim to stop complaining about /dev/null "changing"?

[xenomachina]

I use a multi-diff tool that uses vim's diff mode, but with one tab for file. When a file has been added or removed, it uses /dev/null for the "missing" side. (So an added file has /dev/null on the left, while a deleted file has /dev/null on the right.)

This works fine with gvim on Linux, and it works fine with terminal-mode vim on Linux or macOS. However, MacVim keeps complaining that "File '/dev/null' has changed since editing started".

Is this a bug, or a configuration issue, or what? Is there any way I can get it to stop complaining about /dev/null changing without disabling change detection for other files?

[ychin]

Hmm, deviations from vanilla Vim does make it sound like a bug, but can you share the actual diff tool you are using and how you are invoking it? Is it invoked from Git (using git difftool) or other methods? If it's Git can you share the Git configs related to that diff tool? I'm just not clear why it's using /dev/null for this.

To be clearer, it would be nice if there are clear repro steps that others can follow along.

[xenomachina]

You can reproduce this with git difftool. To set it up:

1. Create a symlink in your $PATH called gvimdiff that links to /Applications/MacVim.app/Contents/bin/mvim.

2. In .gitconfig:

   [difftool]
     prompt = false
   [diff]
     tool = gvimdiff
   

(There may be a cleaner way to do this, but git difftool doesn't just let you specify an arbitrary command for its tool setting.)

You'll then need some changes to diff in a git repo that add new files and/or delete existing files. Instead of using git diff to view them, use git difftool.

For each file being diffed it'll run gvimdiff (really mvim, due to the symlink) with a pair of file names: the "old" version and the "new" version. Use :qa to quit and move onto the next file.

For the case where a file is added or deleted you'll see that it uses /dev/null for the "missing" half of the pair.

[xenomachina]

An even easier way to reproduce:

1. :set hidden
2. :e /dev/null
3. :enew
4. :bd

When you delete the second (unnamed) buffer, it'll switch back to the /dev/null buffer, and then the file changed warning will appear.

This reproduces it even with mvim -u NONE -U NONE.

[ychin]

I can reproduce this. Let me take a look.

[ychin]

it works fine with terminal-mode vim on Linux or macOS

@xenomachina are you sure you have never seen this on other versions of Vim? I just tested this on the latest vanilla Vim on macOS terminal, and I can reproduce this, so it kind of seems like a Vim bug rather than a MacVim thing. What kind of versions did you test on and did you use the same method to test?

[xenomachina]

Sorry for my late reply. I was never able to get this to reproduce on any version of vim but MacVim.

However, I eventually found that adding this to my .vimrc prevented the warnings from appearing:

autocmd BufEnter /dev/null set buftype=nofile