Loading ...
Sorry, an error occurred while loading the content.
 

Re: vim get mess in tmux after xorg restart.

Expand Messages
  • Yukihiro Nakadaira
    ... When X connection lost, Vim uses longjmp() (Jump from os_unix.c:x_IOerror_handler() to main.c:999). While processing vgetorpeek(), it may occur. And when
    Message 1 of 3 , Oct 1, 2011
      2011/10/2 Yue Wu <vanopen@...>:
      > Hello list,
      >
      > I'm running vim in a tmux session in xterm, I find that, when I quit
      > Xorg and start it again, then restore tmux session in a xterm, the
      > running vim will get mess, the keybindings and functions of the plugins
      > will get lost, I have to restart vim to make it back into normal
      > condition.
      >
      > What's wrong?

      When X connection lost, Vim uses longjmp() (Jump from
      os_unix.c:x_IOerror_handler() to main.c:999).
      While processing vgetorpeek(), it may occur.
      And when it occur, vgetc_busy global variable is not reset (Normally it
      is reset at end of vgetorpeek()).
      Then after longjmp(), mappings are never applied because vgetc_busy > 0
      is always true.
      I think there is other situation that longjmp() breaks something.


      main.c:
      994 #if defined(FEAT_X11) && defined(FEAT_XCLIPBOARD)
      995 /* Setup to catch a terminating error from the X server. Just ignore
      996 * it, restore the state and continue. This might not always work
      997 * properly, but at least we don't exit unexpectedly when the X server
      998 * exists while Vim is running in a console. */
      999 if (!cmdwin && !noexmode && SETJMP(x_jump_env))
      1000 {
      1001 State = NORMAL;
      1002 # ifdef FEAT_VISUAL
      1003 VIsual_active = FALSE;
      1004 # endif
      1005 got_int = TRUE;
      1006 need_wait_return = FALSE;
      1007 global_busy = FALSE;


      ad-hoc fix.

      diff -r 15b934a16641 src/main.c
      --- a/src/main.c Wed Sep 14 19:04:40 2011 +0200
      +++ b/src/main.c Sun Sep 25 18:50:43 2011 +0900
      @@ -1009,6 +1009,7 @@
      skip_redraw = FALSE;
      RedrawingDisabled = 0;
      no_wait_return = 0;
      + vgetc_busy = 0;
      # ifdef FEAT_EVAL
      emsg_skip = 0;
      # endif


      --
      Yukihiro Nakadaira - yukihiro.nakadaira@...

      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php
    • Bram Moolenaar
      ... Thanks. I ll put it on the todo list. -- Change is inevitable, except from a vending machine. /// Bram Moolenaar -- Bram@Moolenaar.net --
      Message 2 of 3 , Oct 2, 2011
        Yukihiro Nakadaira wrote:

        > 2011/10/2 Yue Wu <vanopen@...>:
        > > Hello list,
        > >
        > > I'm running vim in a tmux session in xterm, I find that, when I quit
        > > Xorg and start it again, then restore tmux session in a xterm, the
        > > running vim will get mess, the keybindings and functions of the plugins
        > > will get lost, I have to restart vim to make it back into normal
        > > condition.
        > >
        > > What's wrong?
        >
        > When X connection lost, Vim uses longjmp() (Jump from
        > os_unix.c:x_IOerror_handler() to main.c:999).
        > While processing vgetorpeek(), it may occur.
        > And when it occur, vgetc_busy global variable is not reset (Normally it
        > is reset at end of vgetorpeek()).
        > Then after longjmp(), mappings are never applied because vgetc_busy > 0
        > is always true.
        > I think there is other situation that longjmp() breaks something.
        >
        >
        > main.c:
        > 994 #if defined(FEAT_X11) && defined(FEAT_XCLIPBOARD)
        > 995 /* Setup to catch a terminating error from the X server. Just ignore
        > 996 * it, restore the state and continue. This might not always work
        > 997 * properly, but at least we don't exit unexpectedly when the X server
        > 998 * exists while Vim is running in a console. */
        > 999 if (!cmdwin && !noexmode && SETJMP(x_jump_env))
        > 1000 {
        > 1001 State = NORMAL;
        > 1002 # ifdef FEAT_VISUAL
        > 1003 VIsual_active = FALSE;
        > 1004 # endif
        > 1005 got_int = TRUE;
        > 1006 need_wait_return = FALSE;
        > 1007 global_busy = FALSE;
        >
        >
        > ad-hoc fix.

        Thanks. I'll put it on the todo list.


        --
        Change is inevitable, except from a vending machine.

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ an exciting new programming language -- http://www.Zimbu.org ///
        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php
      Your message has been successfully submitted and would be delivered to recipients shortly.