Starting cli vim without any X connection?
Richard Hartmann
when starting vim under X but without a valid magic cookie, vim spams
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified
into my edit buffer. Of course, I could just
ln -s ~user/.Xauthority ~/
as root, but I feel I should not need to, especially as I don't use any X
extensions, anyway. As a side note, the errors resist a :redraw, you
need to :redraw! to make them go away. No idea why, as they appear
in the middle of the edit buffer, not in the status line.
And no, I am not loading anything that would need X,
vim -u none -U none
shows the same behaviour
Any help appreciated,
Richard
Tony Mechelynck
If your vim executable is X-enabled but you don't want to let it connect to X
this time, use
vim -X
Of course, that means no clipboard and no client-server facilities.
Best regards,
Tony.
--
Once there lived a village of creatures along the bottom of a
great crystal river. Each creature in its own manner clung tightly to
the twigs and rocks of the river bottom, for clinging was their way of
life, and resisting the current what each had learned from birth. But
one creature said at last, "I trust that the current knows where it is
going. I shall let go, and let it take me where it will. Clinging, I
shall die of boredom."
The other creatures laughed and said, "Fool! Let go, and that
current you worship will throw you tumbled and smashed across the
rocks, and you will die quicker than boredom!"
But the one heeded them not, and taking a breath did let go,
and at once was tumbled and smashed by the current across the rocks.
Yet, in time, as the creature refused to cling again, the current
lifted him free from the bottom, and he was bruised and hurt no more.
And the creatures downstream, to whom he was a stranger, cried,
"See a miracle! A creature like ourselves, yet he flies! See the
Messiah, come to save us all!" And the one carried in the current
said, "I am no more Messiah than you. The river delight to lift us
free, if only we dare let go. Our true work is this voyage, this
adventure.
But they cried the more, "Saviour!" all the while clinging to
the rocks, making legends of a Saviour.
Richard Hartmann
> If your vim executable is X-enabled but you don't want to let it connect to X
> this time, use
>
> vim -X
>
> Of course, that means no clipboard and no client-server facilities.
Thanks a lot :) As I really only use vim without _any_ X stuff, I will
prolly just
alias this. :he -X does not mention any RC option I could set to achieve the
same effect. On the other hand, I don't know how many people could use a
:set nox
and if it is not too late to set this in an RC file.
Richard
Tony Mechelynck
If you really want never to use X, I recommend compiling without GUI and
without X, i.e.
export CONF_OPT_GUI='--disable-gui --without-x'
[export other configure settings]
make reconfig 2>&1 |tee config.log
make install 2>&1 |tee install.log
Then Vim will never try to establish any connection with an X11 server (and it
will always start in console mode too, of course).
To disable the X connection for some terminals only, see ":help 'clipboard'"
For instance:
:set clipboard+=exclude:linux
You could use ":set clipboard=exclude:.*" to always forbid connecting with X,
but then you'd be using a GUI-enabled binary with a lot of never-used ballast
in it.
It isn't clear to me at exactly which point of startup Vim attempts (if
enabled) to make contact with an X server.
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
112. You are amazed that anyone uses a phone without a modem on it...let
alone hear actual voices.
Rodolfo Borges
> If you really want never to use X, I recommend compiling without GUI and
> without X, i.e.
I second that. And your vim will start faster, and still work if the X
libraries are broken, or not installed. Running ldd on the vim
installed by ubuntu shows 40 libraries. Compiling my own, it's just 4.
You can also have a separate vim and gvim executables.
> It isn't clear to me at exactly which point of startup Vim attempts (if
> enabled) to make contact with an X server.
The connection should be opened only when demanded.
By the way, it would be nice to have .so plugins (apart from the Vim
script plugins). That would solve these problems, and you would still
be able to use all the fancy stuff only when you need.
Gary Johnson
> > It isn't clear to me at exactly which point of startup Vim attempts (if
> > enabled) to make contact with an X server.
>
> The connection should be opened only when demanded.
A vim built with certain X features (e.g., "Normal version with GTK
GUI") attempts to connect to the X server during startup, even when
run as "vim -u NONE".
Gary
Tony Mechelynck
>> Richard Hartmann wrote:
>> If you really want never to use X, I recommend compiling without GUI and
>> without X, i.e.
>
> I second that. And your vim will start faster, and still work if the X
> libraries are broken, or not installed. Running ldd on the vim
> installed by ubuntu shows 40 libraries. Compiling my own, it's just 4.
> You can also have a separate vim and gvim executables.
>
>
>> It isn't clear to me at exactly which point of startup Vim attempts (if
>> enabled) to make contact with an X server.
>
> The connection should be opened only when demanded.
An X-aware Vim will (even when started in console mode) try to establish
contact with an X server at startup, and if it can't, disable clipboard
access; but at which point of startup?
>
>
> By the way, it would be nice to have .so plugins (apart from the Vim
> script plugins). That would solve these problems, and you would still
> be able to use all the fancy stuff only when you need.
Then they wouldn't be cross-platform, and we'd need to distribute not only
binary lib*.so plugins for Linux, but also *.dll for Windows, lib*.dylib for
the Mac, and what would we distribute for Amiga or VMS? If you need fancy
stuff, don't build the kitchen sink into Vim, call an external program, or
interface either linewise or sriptwise with an interpreter (Vim itself remains
my interpreter of choice for that -- in vimscript, I mean -- but there are
also perl, python, tcl, ruby and now Scheme; which aren't always compiled-in
however: tanstaafl).
Best regards,
Tony.
--
For your penance, say five Hail Marys and one loud BLAH!
Yongwei Wu
>
> Rodolfo Borges wrote:
> > By the way, it would be nice to have .so plugins (apart from the Vim
> > script plugins). That would solve these problems, and you would still
> > be able to use all the fancy stuff only when you need.
I second this.
> Then they wouldn't be cross-platform, and we'd need to distribute
> not only binary lib*.so plugins for Linux, but also *.dll for
> Windows, lib*.dylib for the Mac, and what would we distribute for
> Amiga or VMS?
Why is that a problem? If I want something binary to solve a problem,
it is by definition not cross-platform. However, this does not
prevent people from providing the source to compile on other
platforms. Nobody blames Firefox/Mozilla/Netscape to have a plug-in
architecture, right?
> If you need fancy stuff, don't build the kitchen sink into Vim, call
> an external program, or interface either linewise or sriptwise with
> an interpreter (Vim itself remains my interpreter of choice for that
> -- in vimscript, I mean -- but there are also perl, python, tcl,
> ruby and now Scheme; which aren't always compiled-in however:
> tanstaafl).
One counterexample: starting a new process is much slower in Windows
than in Linux; if one uses a console program, which is the easiest way
for communication (to use command-line, stdin, and stdout for I/O), a
black window will flash when the program is run under a gVim. If we
have a standard C plug-in interface (like in a browser), some jobs
will be smoother.
Best regards,
Yongwei
--
Wu Yongwei
URL: http://wyw.dcweb.cn/
Tony Mechelynck
> On 05/11/2007, Tony Mechelynck <antoine.m...@gmail.com> wrote:
>> Rodolfo Borges wrote:
>>> By the way, it would be nice to have .so plugins (apart from the Vim
>>> script plugins). That would solve these problems, and you would still
>>> be able to use all the fancy stuff only when you need.
>
> I second this.
>
>> Then they wouldn't be cross-platform, and we'd need to distribute
>> not only binary lib*.so plugins for Linux, but also *.dll for
>> Windows, lib*.dylib for the Mac, and what would we distribute for
>> Amiga or VMS?
>
> Why is that a problem? If I want something binary to solve a problem,
> it is by definition not cross-platform. However, this does not
> prevent people from providing the source to compile on other
> platforms. Nobody blames Firefox/Mozilla/Netscape to have a plug-in
> architecture, right?
Right; I don't blame them, but I feel like their (binary) plugins are on the
downhill way. There are plugins for a handful of tasks like displaying PDF
files or flash videos, or running Java applets; but there are hudreds or maybe
thousands of extensions, which are essentially zipped sets of text files.
IIUC, the only binaries in them are images (icons for buttons etc.).
>
>> If you need fancy stuff, don't build the kitchen sink into Vim, call
>> an external program, or interface either linewise or sriptwise with
>> an interpreter (Vim itself remains my interpreter of choice for that
>> -- in vimscript, I mean -- but there are also perl, python, tcl,
>> ruby and now Scheme; which aren't always compiled-in however:
>> tanstaafl).
>
> One counterexample: starting a new process is much slower in Windows
> than in Linux; if one uses a console program, which is the easiest way
> for communication (to use command-line, stdin, and stdout for I/O), a
> black window will flash when the program is run under a gVim. If we
> have a standard C plug-in interface (like in a browser), some jobs
> will be smoother.
>
> Best regards,
>
> Yongwei
>
I think you underestimate the power of vimscript (or that you overestimate the
putative power of a hypothetical binary-plugin interface).
Best regards,
Tony.
--
"I think the sky is blue because it's a shift from black through purple
to blue, and it has to do with where the light is. You know, the
farther we get into darkness, and there's a shifting of color of light
into the blueness, and I think as you go farther and farther away from
the reflected light we have from the sun or the light that's bouncing
off this earth, uh, the darker it gets ... I think if you look at the
color scale, you start at black, move it through purple, move it on
out, it's the shifting of color. We mentioned before about the stars
singing, and that's one of the effects of the shifting of colors."
-- Pat Robertson, The 700 Club
Gary Johnson
> On 05/11/2007, Tony Mechelynck <antoine.m...@gmail.com> wrote:
> > Then they wouldn't be cross-platform, and we'd need to distribute
> > not only binary lib*.so plugins for Linux, but also *.dll for
> > Windows, lib*.dylib for the Mac, and what would we distribute for
> > Amiga or VMS?
>
> Why is that a problem? If I want something binary to solve a problem,
> it is by definition not cross-platform. However, this does not
> prevent people from providing the source to compile on other
> platforms. Nobody blames Firefox/Mozilla/Netscape to have a plug-in
> architecture, right?
And I use the same Firefox plugins for both Linux and Windows. I
believe they are written in Java so that they will be
platform-independent, as long as they don't use any
platform-specific functions.
> > If you need fancy stuff, don't build the kitchen sink into Vim, call
> > an external program, or interface either linewise or sriptwise with
> > an interpreter (Vim itself remains my interpreter of choice for that
> > -- in vimscript, I mean -- but there are also perl, python, tcl,
> > ruby and now Scheme; which aren't always compiled-in however:
> > tanstaafl).
>
> One counterexample: starting a new process is much slower in Windows
> than in Linux; if one uses a console program, which is the easiest way
> for communication (to use command-line, stdin, and stdout for I/O), a
> black window will flash when the program is run under a gVim. If we
> have a standard C plug-in interface (like in a browser), some jobs
> will be smoother.
I think that's what Tony meant by TANSTAAFL--There Ain't No Such
Thing As A Free Lunch. It is significantly easier for everyone if
all the platform-dependent stuff is confined within vim/gvim and any
external interpreters. Plugin writers don't have to concern
themselves (very much) with platform issues and plugin users don't
have to concern themselves with compilers, library dependencies,
etc. For that convenience, you pay a little in performance. I've
never encountered a significant performance problem myself that
would be solved by moving the code from a script to C.
Regards,
Gary
Tony Mechelynck
[...]
> And I use the same Firefox plugins for both Linux and Windows. I
> believe they are written in Java so that they will be
> platform-independent, as long as they don't use any
> platform-specific functions.
Unlike the extensions (which are .xpi archives of text files, be they XUL,
HTML, CSS, RDF, Javascript -- not Java --, plus maybe a few images, probably
in .xpm or .gif; and these .xpi extensions are often cross-platform), the
plugins are *.dll BINARY SHARED LIBRARIES on Windows, *.so on Linux, etc. Most
"plugin manufacturers" (such as Adobe) make a Windows version, a Linux version
and a Mac version of their plugins, so you can use an "Acrobat plugin" or a
"Flash plugin" on Linux, Windows or Mac, but it's not "the same" file: if you
took nppdf32.dll (the Acrobat plugin for Netscape-like browsers on 32-bit
Windows) from a Windows machine, renamed it libnppdf.so, and tried to use it
on a Linux machine "as if it were" Adobe's libnppdf.so (the Acrobat plugin for
Netscape-like browsers on Linux), _it_ _just_ _wouldn't_ _work_.
Best regards,
Tony.
--
You know it's going to be a bad day when you want to put on the clothes
you wore home from the party and there aren't any.
Yongwei Wu
> overestimate the putative power of a hypothetical binary-plugin
> interface).
Hi Tony,
You agree that calling an external program is sometimes necessary,
right? Then why do you think calling an external DLL is a bad idea?
I would say on Linux it may not be necessary, but, as I mentioned,
starting a new process on Windows can be slow and ugly.
I really have a specific need to use the assumed plug-in interface.
Currently, FencView+tellenc has a flashing window when detecting the
encoding of a text file on Windows, and I would be very happy to get
rid of the window. -- With some security software (e.g., an intrustion
prevention system that I do not want to name), the window will even
stay on the screen for half a second. -- BTW, scanning a 100 KB file
does take some time.
Tony Mechelynck
[...]
> You agree that calling an external program is sometimes necessary,
> right? Then why do you think calling an external DLL is a bad idea?
> I would say on Linux it may not be necessary, but, as I mentioned,
> starting a new process on Windows can be slow and ugly.
We-e-ell... You're making me think. A .dll, like an .exe, is external, binary
and executable, so there are obvious similarities. In addition, a .dll is
supposed to be "shareable" between several concurrent processes, so one could
even argue that a .dll is "better" than an .exe. However, that "advantage"
largely disappears in the case of a "plugin" .dll, if it is dedicated to one
particular application and meant to be used only with it. (Netscape plugins
can be used with Netscape, Firefox, SeaMonkey, or, on other OSes, Konqueror
and, I think, Safari; but most users use only one browser, at least most of
the time.) "Running" external programs (as invoked in Vim by :! or system())
usually applies to .exe programs, though one "program" which could be invoked
that way -- on Windows only -- is RUNDLL32.EXE, so here too the distinction
fades. Hm, talking of plugins, what about
:let s:result = system('rundll32 c:\some\path\to\myplugin.dll blah blah blah...')
? Wouldn't that (on Windows) satisfy most of your requirements?
>
> I really have a specific need to use the assumed plug-in interface.
> Currently, FencView+tellenc has a flashing window when detecting the
> encoding of a text file on Windows, and I would be very happy to get
> rid of the window. -- With some security software (e.g., an intrustion
> prevention system that I do not want to name), the window will even
> stay on the screen for half a second. -- BTW, scanning a 100 KB file
> does take some time.
>
> Best regards,
>
> Yongwei
>
Best regards,
Tony.
--
`Just the place for a Snark!' the Bellman cried,
As he landed his crew with care;
Supporting each man on the top of the tide
By a finger entwined in his hair.
'Just the place for a Snark! I have said it twice:
That alone should encourage the crew.
Just the place for a Snark! I have said it thrice:
What I tell you three times is true.'
Gary Johnson
> Gary Johnson wrote:
> [...]
> > And I use the same Firefox plugins for both Linux and Windows. I
> > believe they are written in Java so that they will be
> > platform-independent, as long as they don't use any
> > platform-specific functions.
> [...]
>
> Unlike the extensions (which are .xpi archives of text files, be they XUL,
> HTML, CSS, RDF, Javascript -- not Java --, plus maybe a few images, probably
> in .xpm or .gif; and these .xpi extensions are often cross-platform), the
> plugins are *.dll BINARY SHARED LIBRARIES on Windows, *.so on Linux, etc. Most
> "plugin manufacturers" (such as Adobe) make a Windows version, a Linux version
> and a Mac version of their plugins, so you can use an "Acrobat plugin" or a
> "Flash plugin" on Linux, Windows or Mac, but it's not "the same" file: if you
> took nppdf32.dll (the Acrobat plugin for Netscape-like browsers on 32-bit
> Windows) from a Windows machine, renamed it libnppdf.so, and tried to use it
> on a Linux machine "as if it were" Adobe's libnppdf.so (the Acrobat plugin for
> Netscape-like browsers on Linux), _it_ _just_ _wouldn't_ _work_.
Right. I confused "plugin" with "extension". Thanks for setting me
straight.
Regards,
Gary
Yongwei Wu
> [...]
> > You agree that calling an external program is sometimes necessary,
> > right? Then why do you think calling an external DLL is a bad idea?
> > I would say on Linux it may not be necessary, but, as I mentioned,
> > starting a new process on Windows can be slow and ugly.
>
> We-e-ell... You're making me think. A .dll, like an .exe, is external, binary
> and executable, so there are obvious similarities. In addition, a .dll is
> supposed to be "shareable" between several concurrent processes, so one could
> even argue that a .dll is "better" than an .exe. However, that "advantage"
> largely disappears in the case of a "plugin" .dll, if it is dedicated to one
> particular application and meant to be used only with it. (Netscape plugins
> can be used with Netscape, Firefox, SeaMonkey, or, on other OSes, Konqueror
> and, I think, Safari; but most users use only one browser, at least most of
> the time.) "Running" external programs (as invoked in Vim by :! or system())
> usually applies to .exe programs, though one "program" which could be invoked
> that way -- on Windows only -- is RUNDLL32.EXE, so here too the distinction
> fades. Hm, talking of plugins, what about
>
> :let s:result = system('rundll32 c:\some\path\to\myplugin.dll blah blah blah...')
>
> ? Wouldn't that (on Windows) satisfy most of your requirements?
No, you did not get to my pain points. My problem is exactly that
starting a new process is slow and possibly ugly. So I would like
to have a way to load a binary extension without launching new
processes, and a defined way for communication between Vim/extension
and the plug-in.
> > I really have a specific need to use the assumed plug-in interface.
> > Currently, FencView+tellenc has a flashing window when detecting the
> > encoding of a text file on Windows, and I would be very happy to get
> > rid of the window. -- With some security software (e.g., an intrustion
> > prevention system that I do not want to name), the window will even
> > stay on the screen for half a second. -- BTW, scanning a 100 KB file
> > does take some time.
Best regards,
Yongwei
--
Tony Mechelynck
My pleasure. Re-reading my previous post here, it sounds like I failed to keep
my usual calm. Thanks for keeping yours and not escalating into a stupid flame
war.
Best regards,
Tony.
--
Santa Claus wears a Red Suit,
He must be a communist.
And a beard and long hair,
Must be a pacifist.
What's in that pipe that he's smoking?
-- Arlo Guthrie
Yongwei Wu
> [...]
> > You agree that calling an external program is sometimes necessary,
> > right? Then why do you think calling an external DLL is a bad idea?
> > I would say on Linux it may not be necessary, but, as I mentioned,
> > starting a new process on Windows can be slow and ugly.
>
> We-e-ell... You're making me think. A .dll, like an .exe, is external, binary
> and executable, so there are obvious similarities. In addition, a .dll is
> supposed to be "shareable" between several concurrent processes, so one could
> even argue that a .dll is "better" than an .exe. However, that "advantage"
> largely disappears in the case of a "plugin" .dll, if it is dedicated to one
> particular application and meant to be used only with it. (Netscape plugins
> can be used with Netscape, Firefox, SeaMonkey, or, on other OSes, Konqueror
> and, I think, Safari; but most users use only one browser, at least most of
> the time.) "Running" external programs (as invoked in Vim by :! or system())
> usually applies to .exe programs, though one "program" which could be invoked
> that way -- on Windows only -- is RUNDLL32.EXE, so here too the distinction
> fades. Hm, talking of plugins, what about
>
> :let s:result = system('rundll32 c:\some\path\to\myplugin.dll blah blah blah...')
>
> ? Wouldn't that (on Windows) satisfy most of your requirements?
No, you did not get to my pain points. My problem is exactly that
starting a new process is slow and possibly ugly. So I would like
to have a way to load a binary extension without launching new
processes, and a defined way for communication between Vim/extension
and the plug-in.
> > I really have a specific need to use the assumed plug-in interface.
> > Currently, FencView+tellenc has a flashing window when detecting the
> > encoding of a text file on Windows, and I would be very happy to get
> > rid of the window. -- With some security software (e.g., an intrustion
> > prevention system that I do not want to name), the window will even
> > stay on the screen for half a second. -- BTW, scanning a 100 KB file
> > does take some time.
Best regards,
Yongwei
--
Tony Mechelynck
If you check the "processes list" of the Windows Task Manager, you'll notice
that every .dll _is_ a separate process; it's just (IIUC) the invocation
method which is different: a DLL has (usually) more than one entry points.
What about setting 'shell' to rundll32 and the other 'shellsomething' options
to whatever we need...? Oh, well, I guess I'm fighting a losing battle.
> Best regards,
>
> Yongwei
>
Best regards,
Tony.
--
In specifications, Murphy's Law supersedes Ohm's.
Yongwei Wu
No. Have you found the process npswf32.dll?
> What about setting 'shell' to rundll32 and the other 'shellsomething' options
> to whatever we need...? Oh, well, I guess I'm fighting a losing battle.
:-) If you had a concrete proposal to solve my problems, I would be
happy to see it.
Sadly the demand for plug-in is not strong enough for Bram to do some
real work.
Tony Mechelynck
Which one is that? Are you sure it's running? I remember (IIRC, of course)
seeing USER32.DLL AND GUI32.DLL as other than KERNEL32, er, is that one a .dll
or an .exe?
>
>> What about setting 'shell' to rundll32 and the other 'shellsomething' options
>> to whatever we need...? Oh, well, I guess I'm fighting a losing battle.
>
> :-) If you had a concrete proposal to solve my problems, I would be
> happy to see it.
>
> Sadly the demand for plug-in is not strong enough for Bram to do some
> real work.
You 're always welcome, of course, to branch off a "plugin-enabled" version
off the Vim source tree; but of course such endeavours require care and
dedication, if they aren't to go the way of kvim...
>
> Best regards,
>
> Yongwei
>
Best regards,
Tony.
--
77. HO HUM -- The Redundant
------- (7) This hexagram refers to a situation of extreme
--- --- (8) boredom. Your programs always bomb off. Your wife
------- (7) smells bad. Your children have hives. You are working
---O--- (6) on an accounting system, when you want to develop the
---X--- (9) GREAT AMERICAN COMPILER. You give up hot dates to
--- --- (8) nurse sick computers. What you need now is sex.
Nine in the second place means:
The yellow bird approaches the malt shop. Misfortune.
Six in the third place means:
In former times men built altars to honor the Internal Revenue
Service. Great Dragons! Are you in trouble!
Ben Schmidt
>>> that every .dll _is_ a separate process; it's just (IIUC) the invocation
>>> method which is different: a DLL has (usually) more than one entry points.
No, every DLL is most certainly not a separate process or there would be an awful
lot more of them. Nor is a DLL necessarily something that 'runs' in the
traditional sense and as such it doesn't even have to have an 'entry point'. DLLs
are essentially bunches of functions that a program can load and use as desired.
Rundll32 allows a DLL to be started as a process, by using one of its functions as
an entry point. I presume the reason this is done is so you can load the DLL once
and then just run different functions it provides without needing to reload it.
Rundll32 will just latch on to the copy already in memory. Not all DLLs are used
like this, though. Others adhere to other interface conventions, whether plugin
architectures for certain programs, the COM object model, or others.
>> Sadly the demand for plug-in is not strong enough for Bram to do some
>> real work.
I, like others, also don't see a need for it. I seem to recall you mentioning two
reasons:
1) Speed. Do you have a situation in mind where you honestly have found the launch
time of using an external program or suchlike nastily slow? I haven't experienced
any speed shortage that would make developing a DLL plugin architecture worthwhile.
2) Command window popping up. If you needn't see the output there are ways to
suppress this. One way could involve a change to Vim's code, but I suspect it
would be a small change, though I haven't looked at the relevant parts of Vim. And
I think other solutions, e.g. using a little utility to supress it, would actually
be better, even though a slight speed penalty.
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
Yongwei Wu
>
> >>> If you check the "processes list" of the Windows Task Manager, you'll notice
> >>> that every .dll _is_ a separate process; it's just (IIUC) the invocation
> >>> method which is different: a DLL has (usually) more than one entry points.
>
> No, every DLL is most certainly not a separate process or there would be an awful
> lot more of them. Nor is a DLL necessarily something that 'runs' in the
> traditional sense and as such it doesn't even have to have an 'entry point'. DLLs
> are essentially bunches of functions that a program can load and use as desired.
> Rundll32 allows a DLL to be started as a process, by using one of its functions as
> an entry point. I presume the reason this is done is so you can load the DLL once
> and then just run different functions it provides without needing to reload it.
> Rundll32 will just latch on to the copy already in memory. Not all DLLs are used
> like this, though. Others adhere to other interface conventions, whether plugin
> architectures for certain programs, the COM object model, or others.
>
> >> Sadly the demand for plug-in is not strong enough for Bram to do some
> >> real work.
>
> I, like others, also don't see a need for it. I seem to recall you
> mentioning two reasons:
>
> 1) Speed. Do you have a situation in mind where you honestly have
> found the launch time of using an external program or suchlike
> nastily slow? I haven't experienced any speed shortage that would
> make developing a DLL plugin architecture worthwhile.
I agree it is not a problem in the general case, though it is much
slower on Windows than on Linux. I did encounter one case where the
company IPS made it *very slow* to the point of annoying--10 times
slower, though it is still below one second. Vim was not the one that
got hurt the most; ./configure was. I had to complain to IT to
disable it on my PC. Amazingly it is not noticeable in other
applications, probably because people know that invoking new processes
in Windows is slow and do not rely much on it. ./configure is not
Windowsy.
> 2) Command window popping up. If you needn't see the output there
> are ways to suppress this. One way could involve a change to Vim's
> code, but I suspect it would be a small change, though I haven't
> looked at the relevant parts of Vim. And I think other solutions,
> e.g. using a little utility to supress it, would actually be better,
> even though a slight speed penalty.
Do you have more ideas here? Currently a console program executed
by gVim (e.g., the `system' function) will always generate a console
window, visible on the task bar and clickable.
Ben Schmidt
> slower on Windows than on Linux. I did encounter one case where the
> company IPS made it *very slow* to the point of annoying--10 times
> slower, though it is still below one second. Vim was not the one that
> got hurt the most; ./configure was. I had to complain to IT to
> disable it on my PC. Amazingly it is not noticeable in other
> applications, probably because people know that invoking new processes
> in Windows is slow and do not rely much on it. ./configure is not
> Windowsy.
Mmm. Though it strikes me this and similar situations wouldn't be solvable by a
Vim binary plugin interface!
>> 2) Command window popping up. If you needn't see the output there
>> are ways to suppress this. One way could involve a change to Vim's
>> code, but I suspect it would be a small change, though I haven't
>> looked at the relevant parts of Vim. And I think other solutions,
>> e.g. using a little utility to supress it, would actually be better,
>> even though a slight speed penalty.
>
> Do you have more ideas here? Currently a console program executed
> by gVim (e.g., the `system' function) will always generate a console
> window, visible on the task bar and clickable.
A tiny utility that does some of what is required is here:
http://www.msfn.org/board/Tool_Hide_console_command_line_windo_t49184.html
I'm pretty sure it wouldn't be good enough for Vim's purposes, as I don't think it
will do what it needs to with redirecting standard input and output and so on. But
I imagine one could fairly easily write some code based on that utility or at
least on the Windows APIs it uses to either:
(1), Create a utility that does redirect standard input and output to and from the
program being run, and possibly even doing more like an 'exec' than a 'fork' to
run it which should be at least a bit faster...
Or (2), modify the way gVim starts processes in Windows (which may well already
use Windows APIs in the non-cygwin case) so that with some switch or option or
such, the command window is supressed.
Or, I guess there is an outside chance that with some combination of options and
redirections, it might work with the utility as is. But I somewhat doubt it.
There are various pros and cons to hiding the console window, which I suspect is
why there aren't options to do this already. And there are pros and cons to not
having a console window at all and trying to emulate a terminal/console in gVim,
too--I suspect these are harder to overcome, as I have this sneaking suspicion
many Windows commandline programs call some APIs that assume the command window is
there or something, and thus programs just break if there isn't one (as opposed to
if there is one that's just hidden).
There are some vague thoughts anyway. A bit technical and quite possibly in need
of a developer to flesh them out and make something really work, so perhaps not
all that useful. :-\ But...there they are...
Smiles,
Yongwei Wu
I have a suggestion here. Please look at the bottom to check.
On 06/11/2007, Ben Schmidt <mail_ben...@yahoo.com.au> wrote:
>
> > I agree it is not a problem in the general case, though it is much
> > slower on Windows than on Linux. I did encounter one case where the
> > company IPS made it *very slow* to the point of annoying--10 times
> > slower, though it is still below one second. Vim was not the one that
> > got hurt the most; ./configure was. I had to complain to IT to
> > disable it on my PC. Amazingly it is not noticeable in other
> > applications, probably because people know that invoking new processes
> > in Windows is slow and do not rely much on it. ./configure is not
> > Windowsy.
>
> Mmm. Though it strikes me this and similar situations wouldn't be
> solvable by a Vim binary plugin interface!
Why not solvable? Preload everything and then call a function instead
of invoking a new process, and the process overhead can be avoided.
Things like support for Perl can also be plugged instead of compiled in.
Maybe not as worth while as in a browser.
> >> 2) Command window popping up. If you needn't see the output there
> >> are ways to suppress this. One way could involve a change to Vim's
> >> code, but I suspect it would be a small change, though I haven't
> >> looked at the relevant parts of Vim. And I think other solutions,
> >> e.g. using a little utility to supress it, would actually be better,
> >> even though a slight speed penalty.
> >
> > Do you have more ideas here? Currently a console program executed
> > by gVim (e.g., the `system' function) will always generate a console
> > window, visible on the task bar and clickable.
>
> A tiny utility that does some of what is required is here:
>
> http://www.msfn.org/board/Tool_Hide_console_command_line_windo_t49184.html
>
> I'm pretty sure it wouldn't be good enough for Vim's purposes, as I
> don't think it will do what it needs to with redirecting standard
> input and output and so on. But I imagine one could fairly easily
> write some code based on that utility or at least on the Windows
> APIs it uses to either:
Thanks to the pointer. It is not very useful per se, but with the
technique there I finally found that I only need to change one line in
os_win32.c to achieve what I want (l. 3123):
si.wShowWindow = SW_SHOWMINIMIZED; --> si.wShowWindow = SW_HIDE;
Hi Bram, do you think it a good idea to make an option to switch the
behaviour? I do not think it should be the default, but sometimes it
is useful for certain plug-ins to call external programs.
Ben Schmidt
>>> slower on Windows than on Linux. I did encounter one case where the
>>> company IPS made it *very slow* to the point of annoying--10 times
>>> slower, though it is still below one second. Vim was not the one that
>>> got hurt the most; ./configure was. I had to complain to IT to
>>> disable it on my PC. Amazingly it is not noticeable in other
>>> applications, probably because people know that invoking new processes
>>> in Windows is slow and do not rely much on it. ./configure is not
>>> Windowsy.
>> Mmm. Though it strikes me this and similar situations wouldn't be
>> solvable by a Vim binary plugin interface!
>
> Why not solvable? Preload everything and then call a function instead
> of invoking a new process, and the process overhead can be avoided.
> Things like support for Perl can also be plugged instead of compiled in.
> Maybe not as worth while as in a browser.
I was referring to the main manifestation of the problem: ./configure. Of course
we can't solve ./configure's slowness with a Vim plugin interface!
>>>> 2) Command window popping up. If you needn't see the output there
>>>> are ways to suppress this. One way could involve a change to Vim's
>>>> code, but I suspect it would be a small change, though I haven't
>>>> looked at the relevant parts of Vim. And I think other solutions,
>>>> e.g. using a little utility to supress it, would actually be better,
>>>> even though a slight speed penalty.
>>> Do you have more ideas here? Currently a console program executed
>>> by gVim (e.g., the `system' function) will always generate a console
>>> window, visible on the task bar and clickable.
>> A tiny utility that does some of what is required is here:
>>
>> http://www.msfn.org/board/Tool_Hide_console_command_line_windo_t49184.html
>>
>> I'm pretty sure it wouldn't be good enough for Vim's purposes, as I
>> don't think it will do what it needs to with redirecting standard
>> input and output and so on. But I imagine one could fairly easily
>> write some code based on that utility or at least on the Windows
>> APIs it uses to either:
>
> Thanks to the pointer. It is not very useful per se, but with the
> technique there I finally found that I only need to change one line in
> os_win32.c to achieve what I want (l. 3123):
>
> si.wShowWindow = SW_SHOWMINIMIZED; --> si.wShowWindow = SW_HIDE;
This is exactly the sort of simple change I was referring to.
> Hi Bram, do you think it a good idea to make an option to switch the
> behaviour? I do not think it should be the default, but sometimes it
> is useful for certain plug-ins to call external programs.
I agree this would be a nice function to have. What I'm not sure about is what the
interface to it should be. It strikes me that if it is simply a Vim option, you
could get yourself in quite a bit of trouble with hidden windows waiting for input
or things like that. Or it might apply to commands you don't expect, e.g. if
diffing. Messy, but perhaps better, because you'd have to consciously enable it
for any command/filter/etc. you set up, might be prepending a character to the
name of the command to be run, much like how login shells are prepended with '-'.
You could perhaps even use '-', actually...a minus sign would seem an appropriate
symbol to use to designate a hidden window. It is also Windows specific, of
course, so care would need to be taken to not break anything else by an interface
change. For that reason, too, I don't think adding a barrage of new commands is at
all a good option.
There's my 2c anyway.
Yongwei Wu
> ./configure. Of course we can't solve ./configure's slowness with a
> Vim plugin interface!
Got it.
> > Thanks to the pointer. It is not very useful per se, but with the
> > technique there I finally found that I only need to change one line in
> > os_win32.c to achieve what I want (l. 3123):
> >
> > si.wShowWindow = SW_SHOWMINIMIZED; --> si.wShowWindow = SW_HIDE;
>
> This is exactly the sort of simple change I was referring to.
>
> > Hi Bram, do you think it a good idea to make an option to switch the
> > behaviour? I do not think it should be the default, but sometimes it
> > is useful for certain plug-ins to call external programs.
>
> I agree this would be a nice function to have. What I'm not sure
> about is what the interface to it should be. It strikes me that if
> it is simply a Vim option, you could get yourself in quite a bit of
> trouble with hidden windows waiting for input or things like that.
I know, I know. That is the reason why it should be on by default. I
was thinking about uses in plug-ins like:
if has('win32') && has('gui_running')
let silentcall_bak=&silentcall_bak
set silentcall
endif
let result=system(...)
if has('win32') && has('gui_running')
let &silentcall=silentcall_bak
endif
Maybe it can be an additional argument to system(), but this kind of
change may not be necessary. An option (default off) seems to be more
unintrusive and simpler.
> Or it might apply to commands you don't expect, e.g. if diffing.
> Messy, but perhaps better, because you'd have to consciously enable
> it for any command/filter/etc. you set up, might be prepending a
> character to the name of the command to be run, much like how login
> shells are prepended with '-'. You could perhaps even use '-',
> actually...a minus sign would seem an appropriate symbol to use to
> designate a hidden window.
I am fine with that too. Maybe system_silent() or even silent!()?
> It is also Windows specific, of course, so care would need to be
> taken to not break anything else by an interface change. For that
> reason, too, I don't think adding a barrage of new commands is at
> all a good option.
What do you suggest, then? Not breaking the interface is exactly the
reason I suggest having an option instead.
Ben Schmidt
>> about is what the interface to it should be. It strikes me that if
>> it is simply a Vim option, you could get yourself in quite a bit of
>> trouble with hidden windows waiting for input or things like that.
>
> I know, I know. That is the reason why it should be on by default. I
> was thinking about uses in plug-ins like:
>
> if has('win32') && has('gui_running')
> let silentcall_bak=&silentcall
> endif
> let result=system(...)
> if has('win32') && has('gui_running')
> let &silentcall=silentcall_bak
> endif
Mmm. That would probably be OK, I guess.
What I was getting at is that I think one downside to this approach is that
whether you want to show the window or not doesn't so much depend upon what your
preferences are, which is what Vim options are mostly for, as upon the nature of
the command being run. It is when the command being run doesn't need human input
or visible output that we want to run it without a window--whether it's being used
as a system() call, filter, :! command, or something else again. E.g. it would be
nice to be able to use filters with hidden windows most of the time, but if you
make filters generally have hidden windows, you will end up being bitten if you
want to see the debug output of one or something. By the same token, even setting
this as an option seems a bit broad to me. For instance, I wonder whether there
are possibilities of triggering autocommands, or diff updates, or such by
seemingly harmless commands you might execute in a plugin with silentcall on and
get yourself into trouble. It would be better to be able to specify it on a
command-by-command basis, I think.
>> Or it might apply to commands you don't expect, e.g. if diffing.
>> Messy, but perhaps better, because you'd have to consciously enable
>> it for any command/filter/etc. you set up, might be prepending a
>> character to the name of the command to be run, much like how login
>> shells are prepended with '-'. You could perhaps even use '-',
>> actually...a minus sign would seem an appropriate symbol to use to
>> designate a hidden window.
>
> I am fine with that too. Maybe system_silent() or even silent!()?
I was thinking more of prepending the external command being executed. E.g.:
:!-some_command
:call system('-some_command')
:set makeprg=-some_command
would run some_command without a window.
> What do you suggest, then? Not breaking the interface is exactly the
> reason I suggest having an option instead.
That's the thing, Yongwei...I don't really have any solid suggestion! I'm not sure
what's best, though I lean towards the prepending '-' idea at the moment. There's
a bit of a tension between breaking the interface and doing it safely enough that
it's not too easy to get yourself in hot water with it! I imagine the option could
become fairly popular once people discover it, as it would make things look
significantly nicer, and make them feel faster, but we don't want it to be too
easy for people to end up with hanging processes all over the place!
The main reason I wrote the last post was simply to get some of these thoughts and
issues out in the open so people could discuss them and hopefully come up with a
suitable solution worthy of official inclusion in Vim!
Cheers,
Bram Moolenaar
Yongwei Wu wrote:
> I have a suggestion here. Please look at the bottom to check.
[...]
> Thanks to the pointer. It is not very useful per se, but with the
> technique there I finally found that I only need to change one line in
> os_win32.c to achieve what I want (l. 3123):
>
> si.wShowWindow = SW_SHOWMINIMIZED; --> si.wShowWindow = SW_HIDE;
>
> Hi Bram, do you think it a good idea to make an option to switch the
> behaviour? I do not think it should be the default, but sometimes it
> is useful for certain plug-ins to call external programs.
What exactly is the effect of this change? Why would a "normal" user
want this? We already have too many options, we need to try avoid
adding yet another one.
--
From "know your smileys":
*<|:-) Santa Claus (Ho Ho Ho)
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Yongwei Wu
>
> Yongwei Wu wrote:
>
> > I have a suggestion here. Please look at the bottom to check.
>
> [...]
>
> > Thanks to the pointer. It is not very useful per se, but with the
> > technique there I finally found that I only need to change one line in
> > os_win32.c to achieve what I want (l. 3123):
> >
> > si.wShowWindow = SW_SHOWMINIMIZED; --> si.wShowWindow = SW_HIDE;
> >
> > Hi Bram, do you think it a good idea to make an option to switch the
> > behaviour? I do not think it should be the default, but sometimes it
> > is useful for certain plug-ins to call external programs.
>
> What exactly is the effect of this change? Why would a "normal" user
> want this? We already have too many options, we need to try avoid
> adding yet another one.
Hi Bram,
I am not expecting a "normal user" will use it. I do expect plug-in
authors will take advantage of it--I would want to, if it is
available--to remove the sometimes distracting console window generated
by the system() call under a graphic Vim. People do not see the
procedure of the executed command in console Vim, anyway.
Another way is to add a new function, or the same system() function
with additional arguments or special form of arguments (Ben's idea).
I doubt it will require bigger modifications and probably not worth
while.
BTW, I have just found that cscope is already run hidden :-). There
used to be a visible console window flashing.
(Hi Ben, I am also commenting on some of your points here.)
No, I do not think we should support such silent execution of external
commands in a generic way. I do not see much use when people may
desire not to see the console window for ":!" or ":make" (but perhaps
for ":silent !"). It seems to me it is most useful with plug-ins
calling external programs.
And we do need to warn users about this special usage in the help
file, be it a parameter to system() or an option. Though system() is
silent already under a console Vim, it is stoppable by Ctrl-C if it
hangs or pauses. Things will be different for the proposed new
change. Document it like:
WARNING: Misuse of this option may cause your Vim to freeze, if the
invoked program pauses for any reason (waiting for user
intervention, etc.). Use it with care.
Though changing options on the fly in a Vim script may not sound as
good as a special function or special parameter, this is what at least
I am doing. In order to make CVS quote special symbols in the user
message correctly, I have code like:
if &shell =~? 'cmd\.exe'
let shellxquotebak=&shellxquote
let &shellxquote='"'
endif
let @z=system($CVSCMD.' '.$CVSOPT.' '.a:cmd.' '.$CVSCMDOPT.' '.filename)
if &shell =~? 'cmd\.exe'
let &shellxquote=shellxquotebak
unlet shellxquotebak
endif
The message in $CVSOPT is already escaped, and works reliably only
when shellxquote=\", if the shell is cmd.exe.