Luc Hermitte wrote:
Hello,
* On Tue, Mar 13, 2007 at 11:29:28PM +0100, A.J.Mechelynck <[EMAIL PROTECTED]>
wrote:
How can a Vim script know if we're running without an X connection?
Of course, some cases are obvious, such as
if has('unix') && !has('x11')
meaning we're on Unix with no X11 support compiled-in.
But what about an X-enabled Vim running in console mode, either with
the -X command-line switch, or in a terminal with no access to an X
server?
[...]
It doesn't take care, however, of the case when an X-enabled Vim was
started as "vim -X" in an xterm. Is there a way to check for that in
vimscript?
What about checking whether .gvimrc is sourced or not?
Testing also for has('x11') could be a way to be sure vim is compiled
for x11, and running with an X connection.
Reading the documentation from |.gvimrc|, it seems there are a few other
way to test for the fact you are running with graphics support.
Unless you want to also support vim running in console, and with X-term
support [1], this should do it. Otherwise, what about testing the
options vim was launched with (thanks to a system('ps
-relevant-options')) ?
HTH,
[1] I don't know whether it is relevant or not.
I'm on Linux, and I definitely want to support Vim running in console. Console
Vim may access the clipboard and clientserver features but only if the
following conditions are all fulfilled:
- compiled with +x11
- compiled with either +clipboard or +clientserver
- running in an X11 terminal emulator (xterm, konsole, gnome-terminal, etc.),
not in a "true" (non-X) console
- the -X switch was not used on the command-line.
The ps solution is difficult to use, because there may be several instances of
Vim running in parallel (whose prognames might or might not be different) and
I want to make sure to access the "current" instance: so I would have to know
the process ID of the current Vim and I don't know how to do that. Using
system('ls -l /proc/self') wouldn't work, because that would return the PID of
the ls process called by a subshell called by Vim.
system('ps -fC ' . v:progname)
will narrow the problem somewhat; but if the result is
UID PID PPID C STIME TTY TIME CMD
root 24547 4008 0 01:42 pts/5 00:00:00 vim
root 24919 3971 0 02:40 pts/2 00:00:00 vim -X
root 24929 25532 1 02:43 tty2 00:00:00 vim
then what? Are we 24547 (without the -X switch), 24919 (with the switch) or
24929 (without the switch, but in /dev/tty2 which cannot access X)?
Maybe I'vound something... or have I?
(first try omitted, it didn't work)
(second try is better)
(third try:)
" (try to) detect whether we have clipboard and X
if has('clipboard')
let x = @+
let @+ = '--' . x
redir @"
silent reg
redir END
let @+ = x
unlet x
let clipboard_present = (@" =~ '^"+ ')
else
let clipboard_present = 0
endif
let X_available = has('x11') && clipboard_present
The above would fail in a Vim compiled with X support but without clipboard
support. I think that that risk is negligible. Do you (or does anyone) see
other cases where the above algorithm would fail? It relies on the fact that
when the clipboard is not available (for whatever reason: not compiled-in, -X,
or terminal with no X access) the ":reg" command never lists the "+ register,
not even if we just yanked a nonempty value into it.
The above clobbers the unnamed register but anyway, I never expect it to be
conserved by "long-timed" operations such as restarting Vim or sourcing a Vim
script. I expect the following results from the above code snippet:
X_available == 0
clipboard_present == 1
non-X with clipboard (e.g. Windows version)
X_available == 1
clipboard_present == 1
Vim is connected to X server (gvim, or Console Vim with X)
X_available == 1
clipboard_present == 0
never
X_available == 0
clipboard_present == 0
no clipboard (for whatever reason)
Best regards,
Tony.
--
Pittsburgh Driver's Test
(8) Pedestrians are
(a) irrelevant.
(b) communists.
(c) a nuisance.
(d) difficult to clean off the front grille.
The correct answer is (a). Pedestrians are not in cars, so they are
totally irrelevant to driving; you should ignore them completely.
