Re: slow startup in gnu screen
- Tony Mechelynck wrote, on 06/27/2008 10:02 PM:
> On 27/06/08 21:15, Michael Goerz wrote:That's the question. To clarify the situation, for simplicity:
>> 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.
> 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
> 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?
- 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
> Best regards,
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php