Emails composed using vim on macOS are sent without any body. If I use an $EDITOR other than vim (i.e Emacs) then it's fine.
I've tested this using vim (8.0) and neovim, both installed via Homebrew, and using each editor's default configuration.
Seeing this as well (vim 8.0 and 8.1). Having a wrapper-script that prevents any initialization fixes it:
/usr/bin/vim -u NONE "$@".
Adding 'No-compatible mode' (-N) make it fail again.
I really can't figure this out. File.read returns EOF for the temporary file written by vim but I don't know why. Looking at the file with 'cat' looks normal. I even looked at it with a hex-Editor and it looks fine i.e. no 0 at the beginning of the file or something like that. I also looked at the permissions and my user owns the file and it belongs to the 'staff' group.
Then I used nano as editor and tried to see any differences between a file created by nano and vim. And again there is no difference I can spot with a hex-Editor. So I looked at the metadata recorded by macOS with 'mdls' and again no difference.
Also there is no difference in permissions between the nano version and the vim version
Anybody any idea what else it could be? I was thinking about the file being still open by vim. But if I breakpoint it and confirm the vim process is quit before continuing it still doesn't work.
When adding the following to my vimrc, it works:
autocmd filetype mail setlocal nobackup nowritebackupCrontab needs this as well. The reason is described here: http://vimdoc.sourceforge.net/htmldoc/options.html#crontab
So aerc might be doing something similar (ie look at the backup-file). Unfortunately my go-knowledge is null.
I can confirm that adding the above line fixed the issue for me too.
Maybe this ticket can be solved by adding a note to the documentation?
I also experienced this issue, and resolved it by setting the following in my aerc.conf to start vim without loading my vimrc.
editor=vim -u NONE
I didn't encounter this anymore with the merged fix, and it lookes like others are fine as well. So I think we can close this issue.