Nothing in register * problem (vim+tmux or vim+screen )

[GoogleCodeExporter]

What steps will reproduce the problem?
1. tmux (or screen)
2. vim
3. Detach from tmux (or screen)
4. Kill X11 server
5. Attach tmux(or screen)
6. Try to copy and paste using yy and p

What is the expected output? What do you see instead?
After copy and paste. It should paste but an error E353: Nothing in register * 
happens.

What version of the product are you using? On what operating system?

VIM - Vi IMproved 7.4
-arabic          +file_in_path    -mouse_sgr       +tag_binary
+autocmd         +find_in_path    -mouse_sysmouse  +tag_old_static
+balloon_eval    +float           -mouse_urxvt     -tag_any_white
+browse          +folding         +mouse_xterm     -tcl
+builtin_terms   -footer          +multi_byte      +terminfo
+byte_offset     +fork()          +multi_lang      +termresponse
+cindent         +gettext         -mzscheme        +textobjects
+clientserver    -hangul_input    +netbeans_intg   +title
+clipboard       +iconv           +path_extra      +toolbar
+cmdline_compl   +insert_expand   -perl            +user_commands
+cmdline_hist    +jumplist        +persistent_undo +vertsplit
+cmdline_info    -keymap          +postscript      +virtualedit
+comments        -langmap         +printer         +visual
-conceal         +libcall         -profile         +visualextra
+cryptv          +linebreak       -python          +viminfo
-cscope          +lispindent      -python3         +vreplace
+cursorbind      +listcmds        +quickfix        +wildignore
+cursorshape     +localmap        +reltime         +wildmenu
+dialog_con_gui  -lua             -rightleft       +windows
+diff            +menu            -ruby            +writebackup
+digraphs        +mksession       +scrollbind      +X11
+dnd             +modify_fname    +signs           -xfontset
-ebcdic          +mouse           +smartindent     +xim
-emacs_tags      +mouseshape      -sniff           +xsmp_interact
+eval            -mouse_dec       +startuptime     +xterm_clipboard
+ex_extra        -mouse_gpm       +statusline      -xterm_save
+extra_search    -mouse_jsbterm   -sun_workshop
-farsi           -mouse_netterm   +syntax

OS: Scientific Linux 5.8

Please provide any additional information below.
The way I am currently using to avoid this problem is to (Inside screen or tmux)
1. :mks!
2. exit vim
3. vim -S Session.vim
Then everything works well again.
Another way to avoid this problem is to
1. :gui
Then I can yank and paste using yy and p inside the newly opened gvim.

I think the problem is happening because vim lost the connection to the X11 
server after killing the X11 server. Would it be possible to make a command 
that makes a new connection to a X11 server inside vim? Or before yanking check 
if a connection to a X11 server is open and if not make a new connection to a 
X11 server?

Original issue reported on code.google.com by fusion...@gmail.com on 6 Mar 2014 at 1:06

[GoogleCodeExporter]

Same issue here with vim 7.4/tmux 1.9a on Arch Linux.

Original comment by keith.hu...@gmail.com on 13 Jul 2014 at 12:46

[GoogleCodeExporter]

Same. Vim 7.4 on OS X 10.9.4. This would be an appreciated fix.

Original comment by vitc...@gmail.com on 17 Jul 2014 at 10:29

[GoogleCodeExporter]

Same here, with iTerm2 which uses tmux under the hood.

Original comment by boi...@gmail.com on 30 Sep 2014 at 10:54

[GoogleCodeExporter]

So looks like it's something related to compiling --with-client-server 
https://github.com/Homebrew/homebrew/issues/32875

Original comment by boi...@gmail.com on 4 Oct 2014 at 4:53

[GoogleCodeExporter]

Also using --with-client-server. The feature is used by some very useful 
plugins (e.g. vim-r: http://www.vim.org/scripts/script.php?script_id=2628).

Original comment by keith.hu...@gmail.com on 6 Oct 2014 at 3:55

[GoogleCodeExporter]

posted patch here: 
https://groups.google.com/d/msg/vim_dev/d_ezt6jn_jU/Kz4EkVFK1DEJ

Original comment by chrisbr...@googlemail.com on 8 Oct 2014 at 7:26

[GoogleCodeExporter]

Should be fixed by patch 7.4.523
It's different from Christian's patch, it only restores the connection after it 
failed.  This is to avoid repeatedly trying to connect when it fails.

Please check if it works.

Original comment by brammool...@gmail.com on 19 Nov 2014 at 5:51

• Changed state: Fixed

[GoogleCodeExporter]

Hello. I have tried patch 7.4.523

It works very nicely if, you run vim on you local computer and kill your local 
X11 server. The local X11 server will start again and everything works fine.

But if you use vim on a server and kill your local X11, then vim will freeze 
and stop working. (Even though the local X11 server is relaunched...)

Original comment by fusion...@gmail.com on 20 Nov 2014 at 9:52

[GoogleCodeExporter]

I haven't had the chance to test the patch yet, but my setup sounds similar -- 
I usually have vim running in a tmux session on one machine, and then work both 
locally from that machine, and remotely from another machine over SSH (with 
ForwardX11).

Original comment by keith.hu...@gmail.com on 20 Nov 2014 at 11:19

[GoogleCodeExporter]

fusionhep: Did you try with Christian's patch instead of patch 7.4.523?

Original comment by brammool...@gmail.com on 20 Nov 2014 at 10:01

[GoogleCodeExporter]

I just tried Christian's patch instead of patch 7.4.523. But it shows the same 
behavior of patch 7.4.523. (As I described above.)

These are the steps I took to use Christian's patch.

Since Christian's patch was posted on Oct 8, 2014, I checked out v7_4_463 (Sep 
29, 2014).

cd vim
hg checkout v7_4_463
patch -p1 < reconnect_x11.diff
cd src
make distclean
make
make install

Original comment by fusion...@gmail.com on 21 Nov 2014 at 12:23

[GoogleCodeExporter]

Can you update your description on how to freeze Vim? I tried locally with two 
different X-Servers and everything worked as expected.

Original comment by chrisbr...@googlemail.com on 21 Nov 2014 at 3:47

[GoogleCodeExporter]

These are the steps to freeze the patched vim.

On terminal
  1. ssh -Y remoteServer
  2. vim (This is done on the remote server)

On your local machine, kill your local X-server. (While vim is running on the 
remote server)

On terminal, you will find that vim(on the remote server) doesn't respond any 
more. 

I have tried this on OSX10.9.5 and on cygwin(Windows). Both show the same 
behavior.

Original comment by fusion...@gmail.com on 21 Nov 2014 at 4:05

[GoogleCodeExporter]

Just by random trial and error, I found a rough fix(?) (I have no knowledge 
about the code, so this should mess something up?) But I hope this will help.

(From Christian's patch) In os_unix.cc at resetup_term_clip(), add the below 
code, (at the start of the method) 

if (app_context != (XtAppContext)NULL){
    XtDestroyApplicationContext(app_context);
    app_context = (XtAppContext)NULL;
}

If you do so, then vim seems to work on remote servers.

Original comment by fusion...@gmail.com on 21 Nov 2014 at 6:44

[GoogleCodeExporter]

I do not understand. If I ssh -Y remote server and then start vim and then kill 
my local X server, then vim will be terminated, right?
Perhaps you can build a debug build of vim and then start that debug Vim 
session and when Vim freezes connect with gdb to it (gdb --pid=pid of vim) and 
then show the output of the bt command of gdb.

Original comment by chrisbr...@googlemail.com on 21 Nov 2014 at 7:40

[GoogleCodeExporter]

If I kill my local X server... vim will(is) not be terminated.

If I used xterm to ssh -Y remote server, run vim, then kill my local X-server, 
xterm(and vim) will be terminated.
If I used a "terminal" to ssh -Y remote server, run gvim, then kill my local 
X-server, gvim will be terminated.
But since I am using a "terminal" to ssh -Y remote server, run vim... I do not 
think vim should terminate if my local X-server is terminated.

Here is bt command of gdb when vim(patched) is frozen.
(gdb) bt
#0  0x0000003411ccc30f in poll () from /lib64/libc.so.6
#1  0x000000341642c80a in _XtWaitForSomething () from /usr/lib64/libXt.so.6
#2  0x000000341642d1ff in XtAppPending () from /usr/lib64/libXt.so.6
#3  0x00000000004e6994 in xterm_update () at os_unix.c:7086
#4  0x00000000004e7ca9 in setup_term_clip () at os_unix.c:6909
#5  0x00000000004e7d7a in resetup_term_clip () at os_unix.c:6808
#6  0x00000000004e8115 in RealWaitForChar (fd=0, msec=0, check_for_gpm=<value 
optimized out>)
    at os_unix.c:5434
#7  0x00000000004e8291 in mch_breakcheck () at os_unix.c:5082
#8  0x00000000004898b5 in vgetorpeek (advance=1) at getchar.c:2074
#9  0x000000000048a7aa in vgetc () at getchar.c:1638
#10 0x0000000000584925 in main_loop (cmdwin=0, noexmode=0) at main.c:1141
#11 0x0000000000587773 in main (argc=<value optimized out>, argv=<value 
optimized out>)
    at main.c:1042

Original comment by fusion...@gmail.com on 21 Nov 2014 at 8:41

[GoogleCodeExporter]

Now I think I understand. This is my OS setup.
local machine: Mac or Windows(Cygwin)
remote server: Linux

If my local machine was Linux, then If I closed the local X-server then that 
would mean the GUI of OS would be closed. But in other OSs, that would not be 
the case.

Then let me tell you how you can freeze vim(on remote server) with a local 
machine being linux.

1. ssh -Y remote server
2. tmux (or screen)
3. vim
4. detach from tmux (or screen)

5. reboot you local machine or reboot your local X-server

6. ssh -Y remote server
7. attach tmux(or screen)

Original comment by fusion...@gmail.com on 22 Nov 2014 at 2:05

[GoogleCodeExporter]

Thanks, I'll try to reproduce it. Unfortunately, I currently do not have a 
remote system with an X Server available. But in any case, this looks like a 
problem in the X11 libraries (_XtWaitForSomething()). I am not sure, there is 
much that Vim can do against.

Original comment by chrisbr...@googlemail.com on 23 Nov 2014 at 1:22

[GoogleCodeExporter]

Here is another way to show the same behavior with one machine.

1. Change runmode of Linux to multi-user text mode. (For RedHat, Edit 
/etc/inittab. For Ubuntu, depends on version.)
2. Reboot machine.
3. Login
4. startx (For Ubuntu, depends on version. Might need to start service gdm or 
lightdm.)
5. (In GUI terminal) tmux
6. (In GUI terminal) vim
7. Logout (This will return you to text mode)
8. startx (For Ubuntu, depends on version. Might need to start service gdm or 
lightdm.)
9. (In GUI termianl) tmux attach

You will find that vim is frozen.

Yes. I also think that it might by a problem with the X11 libraries.

But for some reason, if you add

if (app_context != (XtAppContext)NULL){
    XtDestroyApplicationContext(app_context);
    app_context = (XtAppContext)NULL;
}

to the begining of resetup_term_clip() in os_unix.c, vim doesn't freeze.
So I naively thought that there might be way to work around the X11 library 
problem(?).

If you have any trouble in reproducing the problem, please tell me what Linux 
version you use.

Original comment by fusion...@gmail.com on 24 Nov 2014 at 5:41

[GoogleCodeExporter]

If that works, than good. I cannot reproduce the problem with neither linux 
mint 17 nor with a debian testing system. Nevertheless, I noticed, that 
sometimes the Clipboard connection is not reset. (probably because the flag 
xterm_dpy_was_reset was reset to zero before trying to establish a X11 
connection). So it might be a good idea to have a command to manually force a 
X11 connection.

Original comment by chrisbr...@googlemail.com on 25 Nov 2014 at 6:53

[GoogleCodeExporter]

I'm still affected by the "Nothing in register * problem" on vim 7.4-621 and 
tmux 1.9a. Have this patch been merged yet?

Original comment by alexandr...@gmail.com on 5 Feb 2015 at 6:40

[GoogleCodeExporter]

Problem persists on 7.4-738 + tmux 2.0.

Original comment by keith.hu...@gmail.com on 30 Jun 2015 at 8:41

[GoogleCodeExporter]

It looks like the issue may be to the use of the unnamed clipboard.

Usually I have "set clipboard=unnamed" so that copied text goes to PRIMARY 
system buffer. This works great initially before detaching disconnecting from 
tmux/SSH session.

When I commented out that line in my .vimrc file, copying and pasting no longer 
worked from vim to the OS, but within vim it worked across multiple sessions 
without issues.

Original comment by keith.hu...@gmail.com on 30 Jun 2015 at 8:46