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

Re: slow startup in gnu screen

Expand Messages
  • Michael Goerz
    ... That s the question. To clarify the situation, for simplicity: - I only use screen on terminal emulators running under X (xterm or konsole/yakuake) - I
    Message 1 of 8 , Jun 27, 2008
    • 0 Attachment
      Tony Mechelynck wrote, on 06/27/2008 10:02 PM:
      > On 27/06/08 21:15, Michael Goerz wrote:
      > [...]
      >> Yes! That's it! Running vim -X works fine. However, I'm wondering why
      >> exactly vim fails to connect to the xserver, and if there's anything
      >> that can be done to remedy that. A disadvantage of the '-X' parameter is
      >> that I lose the support for the x clipboard (the "* buffer). It seems
      >> that I can restore that functionality by running ':call serverlist()'
      >> (or putting it in my .vimrc). The command is mentioned in ':help -X',
      >> but I'm not really sure what exactly it does or why it works. It doesn't
      >> really seem from the description in the help file that it activates the
      >> x-clipboard in a vim that's being run with the '-X' switch.
      >> Another disadvantage is that I'll have to hunt down all my uses of vim
      >> in script files (e.g. mutt, subversion) and add the '-X' switch there
      >> too, so that things work fine in screen. From my tests so far it seems
      >> that putting -X with every use of vim, together with a 'call
      >> serverlist()' in my .vimrc gives me a working vim whether or not I'm
      >> using screen. Are there any problems I might run into with this setup?
      >> Does anyone have some further thoughts on the subject?
      >>> I don't understand exactly why it doesn't happen on a fresh instance
      >>> of screen though.
      >> I'm not a 100% sure, but it seems that vim (without '-X') starts
      >> instantly in a fresh screen session, and starts to have the delay once
      >> the connection to the xserver was broken (i.e. by logging out). I'm
      >> wondering if there's some way to repair the x-connection.
      >> Thanks,
      >> Michael
      > If vim was compiled with X11 support, it will try to connect to the X
      > server at startup, even when run in Console mode, in order to check
      > whether it will be able to connect to the X clipboard and/or to receive
      > save-yourself messages when X goes down.
      > There are two ways to "remedy that":
      > - Run vim with the -X command-line parameter
      > - Compile Console vim without X support (e.g., with --disable-gui
      > --without-x).
      > Of course, you won't have access to the clipboard in either case,
      > because the clipboard is a function of the X server.
      > Is there no way you can check the state of the X connection, and start a
      > fresh screen session if the X connection goes down?
      That's the question. To clarify the situation, for simplicity:
      - I only use screen on terminal emulators running under X (xterm or
      - I don't use ssh or other remote terminals where the connection to X
      might be a problem. All my use is local.
      - I may log out of my KDE session, log in again later, and reconnect to
      a running screen session.

      It is this situation where the problem occurs: when reconnecting to
      screen after having logged out and in again, vim takes several seconds
      to start up, which can be fixed by using 'vim -X'. It's just that I'm
      puzzled about why it has a problem connecting to X. The DISPLAY variable
      is set to ':0' at all times. Also, I should add that once vim starts
      (after the delay, without -X), I do have full access to all
      capabilities, i.e. the x-clipboard. So that would mean vim manages to
      connect to X after all...? It's just somewhat confusing. The clipboard
      option is set it its default 'clipboard=autoselect,exclude:cons\|linux'.
      The TERM variable is set to 'screen-bce'.

      I'm still confused why vim has a problem at all in the described
      scenario, and also to what extent my apparent workaround with 'call
      serverlist()' is solid. I feel there should be a way to tell screen
      about the current situation of my X server after picking up an existing
      session, so that vim can connect to the X server in whatever way it
      needs to. I was kinda under the assumption that that's what the DISPLAY
      variable is for: I should be able to connect to pick up a screen
      session, update the DISPLAY variable as necessary (say I originally
      started screen on :0, and now I'm picking up the session on :1), and all
      applications would know what to do and connect to my current X server
      without problems. Seems like things don't quite work that way, and I
      haven't completely figured out what way they do work, and how it all
      fits together.

      > Best regards,
      > Tony.

      You received this message from the "vim_use" maillist.
      For more information, visit http://www.vim.org/maillist.php
    Your message has been successfully submitted and would be delivered to recipients shortly.