After detaching a session running vim, and running another copy of vim elsewhere, and then reattaching to the dtach session, the arrow keys no longer work in the vim session running in dtach.
Reproduction steps:
dtach -c /tmp/dtach-bug vim
<detach>
vim
<exit vim>
dtach -a /tmp/dtach-bug
<try moving around with the arrow keys>
Movement with the arrow keys will no longer work.
If you run vim within another dtach session (such as a bash session) it exhibits the same behavior, unless you exit vim either before detaching, or after reattaching. As soon as vim is exited and restarted, it works fine.
Running dvtm inside a dtach session exhibits similar issues, once you run vim inside it. However, in this case, exiting and restarting vim has no effect; it has the arrow key bug until dvtm itself is restarted.
Verified that this bug exists in 0.8 as well as 0.7.
Also, when triggering the bug inside dvtm, vim's input locks up until you press Ctrl+C. (in both 0.7 and 0.8)
Another situation where the arrow keys die is when the dtach session is reattached after closing the terminal under which it was started. I haven't yet been able to test whether this is because of attaching it to another terminal, or actually because its original terminal was closed.
This is probably because vim is fiddling with the terminal settings when it starts up, and resets it when it exits. When dtach reattaches, your terminal is still set to the vim mode.
My guess is that it is the smkx terminfo setting.
You could try doing: tput smkx;dtach -a /tmp/dtach-bug;tput rmkx
and see if that fixes your problem (you could also try a different TERM type)
Yes, that fixed the issue. Would there be any way to store that terminal setting in the dtach session state?
If a minimal stateful parser was added to dtach, it could probably detect the escape sequences that are sent to change the terminal settings. It would have to handle the possibility of each character of the sequence being sent separately in order to work 100% of the time, which means a simple string comparison may not be adequate.
Unfortunately, this does mean that dtach would no longer be a simple raw relay of the traffic between the program being run and the attaching clients.