Quoting Evan Laforge <qdunkan@gmail.com> on darcs-users:

Actually it's xterm on linux.  I *think* I saw it on iterm2 on OS X as
well.  It doesn't happen with 2.10.1, and does with 2.12.5.

My guess it that it has to do with how darcs prompts put the terminal
into raw mode, then vim of course uses raw mode, somehow the state
saving and restoring gets messed up when you ^Z out and fg back in.
It's easy for me to reproduce:

Record changes in darcs 2.12.5, then say yes to "add a long comment"
where EDITOR=vim.  Now ^Z out of vim, and then fg back.  At that
point, vim is in command mode, but any keys just appear literally on
the screen, so there's no way to save or quit or do anything.  The
only way out is to kill vim from another terminal, at which point
darcs finishes the record (I guess it doesn't mind that vim return
nonzero?).

It seems the resumed editor actually reacts to all the command keys in
the usual way, it's just that escape sequences are printed literally on
the screen, so you can't see what you will get.

I tested with darcs-2.10.2 and it behaves the same as the head. I am now
trying to build 2.10.1...done. Yes! darcs-2.10.1 does not have this bug.
This should narrow it down to the 38 patches between 2.10.1 and 2.10.2.

This did not work out as I planned. My self-built darcs-2.10.2 works,
the ubuntu package version does not. These are the differences in the
output of --exact-version:

ben@yuiitsu[3]:~>diff bad good -y --suppress-common-lines -W 60 | grep
-v compiled
                             >  HTTP-4000.2.23
attoparsec-0.13.0.1          |  attoparsec-0.13.2.2
cryptohash-0.11.6            |  cryptohash-0.11.9
hashable-1.2.3.3             |  hashable-1.2.6.1
                             >  network-2.6.3.3
                             >  network-uri-2.6.1.0
parsec-3.1.9                 |  parsec-3.1.13.0
regex-applicative-0.3.2.1    |  regex-applicative-0.3.3
tar-0.4.2.2                  |  tar-0.4.5.0
text-1.2.2.0                 |  text-1.2.3.0
unix-compat-0.4.1.4          |  unix-compat-0.4.3.1
vector-0.11.0.0              |  vector-0.10.12.3
zlib-0.6.1.1                 |  zlib-0.6.1.2

These all look pretty much unsuspicious to me. Also, the libraries used
in the good version are all newer than those in the bad version. Any
ideas what to do now?

I thought I had tracked it down to a single patch. Without the patch, it
works, when I pull it, it fails. However, fom the content of the patch
it is obvious that it simply /cannot/ cause this failure! So I re-built
completely (by throwing away dist*) and now it works again! Very
strange, perhaps a bug in cabal new-build. So I'll have to do a complete
rebuild from now on which is really inconvenient.