netbeans connection when Vim is not compiled with netbeans_intg
Xavier de Gaye
netbeans_intg feature, the application waits for Vim to establish the
socket connection and Vim silently ignores the "-nb" command line
argument. It is difficult for the user to understand what is wrong.
The attached patch causes Vim to exit with an error message when it is
invoked with "-nb" and not compiled with the netbeans_intg feature.
This is already what is happening when the diff feature is missing and
vim is invoked as vimdiff.
Xavier
Bram Moolenaar
Xavier de Gaye wrote:
The idea looks right: using -nb when it's not supported should make Vim
quit.
The place where you invoke mch_exit() looks a bit weird. Not sure if
this is the best solution. And when compiled without GUI (e.g.,
starting a small version of Vim) this exit won't be reached. Would
someone only use -nb with gvim?
The message should be defined in one place, not twice.
--
hundred-and-one symptoms of being an internet addict:
193. You ask your girlfriend to drive home so you can sit back with
your PDA and download the information to your laptop
/// 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 ///
Xavier de Gaye
>
> Xavier de Gaye wrote:
>
>> When an application forks a Vim that is not compiled with the
>> netbeans_intg feature, the application waits for Vim to establish the
>> socket connection and Vim silently ignores the "-nb" command line
>> argument. It is difficult for the user to understand what is wrong.
>>
>> The attached patch causes Vim to exit with an error message when it is
>> invoked with "-nb" and not compiled with the netbeans_intg feature.
>> This is already what is happening when the diff feature is missing and
>> vim is invoked as vimdiff.
>
> The idea looks right: using -nb when it's not supported should make Vim
> quit.
>
> The place where you invoke mch_exit() looks a bit weird. Not sure if
> this is the best solution. And when compiled without GUI (e.g.,
> starting a small version of Vim) this exit won't be reached. Would
> someone only use -nb with gvim?
>
> The message should be defined in one place, not twice.
Right of course. I will try sending another patch fixing these points.
BTW do you think an implementation of netbeans over Vim console is
acceptable as a Vim patch (as opposed to an external patch such as
those in http://groups.google.com/group/vim_dev/web/vim-patches).
Xavier
Bram Moolenaar
Xavier de Gaye wrote:
> >> When an application forks a Vim that is not compiled with the
> >> netbeans_intg feature, the application waits for Vim to establish the
> >> socket connection and Vim silently ignores the "-nb" command line
> >> argument. It is difficult for the user to understand what is wrong.
> >>
> >> The attached patch causes Vim to exit with an error message when it is
> >> invoked with "-nb" and not compiled with the netbeans_intg feature.
> >> This is already what is happening when the diff feature is missing and
> >> vim is invoked as vimdiff.
> >
> > The idea looks right: using -nb when it's not supported should make Vim
> > quit.
> >
> > The place where you invoke mch_exit() looks a bit weird. Not sure if
> > this is the best solution. And when compiled without GUI (e.g.,
> > starting a small version of Vim) this exit won't be reached. Would
> > someone only use -nb with gvim?
> >
> > The message should be defined in one place, not twice.
>
> Right of course. I will try sending another patch fixing these points.
Good, thanks.
> BTW do you think an implementation of netbeans over Vim console is
> acceptable as a Vim patch (as opposed to an external patch such as
> those in http://groups.google.com/group/vim_dev/web/vim-patches).
If you can make the netbeans interface work for a Vim running in a
console, that sounds like a useful feature. I would include it if it
works properly. However, some programs using the netbeans interface
assume GUI features, such as menus. Thus it's probably only useful
for some applications.
--
hundred-and-one symptoms of being an internet addict:
207. You're given one phone call in prison and you ask them for a laptop.
Xavier de Gaye
>> > ...
>> > The place where you invoke mch_exit() looks a bit weird. Not sure if
>> > this is the best solution. And when compiled without GUI (e.g.,
>> > starting a small version of Vim) this exit won't be reached. Would
>> > someone only use -nb with gvim?
>> >
>> > The message should be defined in one place, not twice.
>>
>> Right of course. I will try sending another patch fixing these points.
>
> Good, thanks.
Attached is a patch that fixes the above issues. It's on top of
version 7.2.28 (subversion revision 1226).
>> BTW do you think an implementation of netbeans over Vim console is
>> acceptable as a Vim patch (as opposed to an external patch such as
>> those in http://groups.google.com/group/vim_dev/web/vim-patches).
>
> If you can make the netbeans interface work for a Vim running in a
> console, that sounds like a useful feature. I would include it if it
> works properly. However, some programs using the netbeans interface
> assume GUI features, such as menus. Thus it's probably only useful
> for some applications.
I will give it a try.
Xavier
sc
> On Sat, Nov 8, 2008 at 2:24 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:
> >> > ...
> >> > The place where you invoke mch_exit() looks a bit weird. Not sure if
> >> > this is the best solution. And when compiled without GUI (e.g.,
> >> > starting a small version of Vim) this exit won't be reached. Would
> >> > someone only use -nb with gvim?
> >> >
> >> > The message should be defined in one place, not twice.
> >>
> >> Right of course. I will try sending another patch fixing these points.
> >
> > Good, thanks.
>
> Attached is a patch that fixes the above issues. It's on top of
> version 7.2.28 (subversion revision 1226).
I hope the above is a typo -- for me subversion reports revision 1226
while vim is at 7.2.26
sc
sc
> >> > ...
> >> > The place where you invoke mch_exit() looks a bit weird. Not sure if
> >> > this is the best solution. And when compiled without GUI (e.g.,
> >> > starting a small version of Vim) this exit won't be reached. Would
> >> > someone only use -nb with gvim?
> >> >
> >> > The message should be defined in one place, not twice.
> >>
> >> Right of course. I will try sending another patch fixing these points.
> >
> > Good, thanks.
>
> Attached is a patch that fixes the above issues. It's on top of
> version 7.2.28 (subversion revision 1226).
oops -- please forgive the double post -- I so often hit Send and
then engage my brain
revision 1226 did indeed update my source to 7.2.28 but as it
stands it will not compile for me (already noted in a previous
post)
sc
Xavier de Gaye
Right, to compile Vim I had to comment out lines 656/657 in ex_cmds.h.
Xavier
Tony Mechelynck
There was an error in patch 7.2.027 (corrected in 7.2.030 and improved
in 7.2.031) which caused compile errors. If you upgrade to the current
source it ought to work.
Best regards,
Tony.
--
According to Kentucky state law, every person must take a bath at least
once a year.
sc
[snip]
> There was an error in patch 7.2.027 (corrected in 7.2.030 and improved
> in 7.2.031) which caused compile errors. If you upgrade to the current
> source it ought to work.
for whatever reason, svn is lagging behind posted patches -- if, like me,
Xavier is waiting on svn, he is stuck at 7.2.28 (since Nov 6)
this is fine for us, but if a newbie comes along expecting to build the
latest and greatest vim by following instructions, he's going to wind up
with sources that won't build -- not good, unless he has the perseverence
to browse this group -- what he'll use to find Xavier's kind response to my
whining I'm not sure, I just hope the experience doesn't turn him into
an emacs user
sc
Tony Mechelynck
Vim SVN is always lagging (sometimes by a week or two) behind CVS. OTOH
the patches appear on the FTP server (and, I think, on CVS which I don't
use) about as fast as they are published on vim_dev. I'm not sure about
A-A-P but I think it uses CVS too. So it's just a question of which
instructions to follow.
On Windows, a newbie doesn't need to build Vim himself (he can just grab
Steve Hall's "cream-less" Vim distributions on sourceforge) so the
question arises mostly on Unix-like systems. As shown on my HowTo page,
what I use is FTP for code and rsync for runtimes: this way I remain
up-to-date. In the rare cases when the FTP site has a hiccup and the
patches don't appear there in timely fashion, I grab the vim_dev post
and check that it has "Content-Transfer-Encoding: 8bit" (or 7bit).
Quoted-printable is not as easy, it must be "doctored" by hand, but it's
doable.
Best regards,
Tony.
--
Friends, Romans, Hipsters,
Let me clue you in;
I come to put down Caesar, not to groove him.
The square kicks some cats are on stay with them;
The hip bits, like, go down under; so let it lay with Caesar. The cool
Brutus
Gave you the message: Caesar had big eyes;
If that's the sound, someone's copping a plea,
And, like, old Caesar really set them straight.
Here, copacetic with Brutus and the studs, -- for Brutus is a real cool cat;
So are they all, all cool cats, --
Come I to make this gig at Caesar's laying down.
Xavier de Gaye
> ...
>>> BTW do you think an implementation of netbeans over Vim console is
>>> acceptable as a Vim patch (as opposed to an external patch such as
>>> those in http://groups.google.com/group/vim_dev/web/vim-patches).
>>
>> If you can make the netbeans interface work for a Vim running in a
>> console, that sounds like a useful feature. I would include it if it
>> works properly. However, some programs using the netbeans interface
>> assume GUI features, such as menus. Thus it's probably only useful
>> for some applications.
>
> I will give it a try.
Attached is a patch that allows Vim to support NetBeans when run in a
terminal. The patch is based on Vim 7.2.160, subversion revision 1440.
Problem: Support the NetBeans interface when Vim is run in a
terminal on Unix.
Solution: Hook the NetBeans file descriptor to the event loop.
Add a backward compatible enhancement: the defineAnnoType
"fg" and "bg" color arguments may also be defined as color
names.
Files: runtime/doc/netbeans.txt src/netbeans.c src/ex_cmds.c
src/proto/netbeans.pro src/gui.c src/getchar.c
src/gui_w48.c src/feature.h src/main.c src/proto.h
src/gui_gtk_x11.c src/os_unix.c
List of the tests that have been run (the pyclewn testsuite is about
50 tests):
Check that a NetBeans session started in a terminal can be
continued after the ":gui" command is run.
Run pyclewn testsuite with GVim compiled with the GTK gui.
Run pyclewn testsuite with Vim in a terminal, compiled with the
GTK gui.
Run pyclewn testsuite with Vim compiled without any gui.
Issue not fixed (not worth fixing ?):
When Vim NetBeans runs in a terminal and the ':gui' command is run
and if the GUI is not one of GTK, GNOME, Motif or Win32, then
NetBeans silently stops working.
Xavier
Bram Moolenaar
Xavier de Gaye wrote:
Thanks, sounds good. I'll have a better look later. I would appreciate
feedback from others.
--
FATHER: You killed eight wedding guests in all!
LAUNCELOT: Er, Well ... the thing is ... I thought your son was a lady.
FATHER: I can understand that.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
Xavier de Gaye
Hi Bram,
I have setup a Mercurial Queues patch at
http://pyclewn.sourceforge.net/vim-patches.html
It will be easier to test this patch and pyclewn 1.1 can now run with
Vim in a console.
The major change from the patch I sent last April, is that netbeans
version has been increased to "2.5".
Using Mercurial Queues for Vim patches, brings the following advantages:
* the patch can be kept in sync with Vim development source tree
* it is easy to test the patch with Vim development source tree
* at any time, one can remove the patch with 'hg qpop'
I will keep this patch in sync with Vim development source tree.
Xavier
Bram Moolenaar
Xavier de Gaye wrote:
I'll move this up in the todo list.
--
From "know your smileys":
:-)-O Smiling doctor with stethoscope
Xavier de Gaye
>
> I have setup a Mercurial Queues patch at
> http://pyclewn.sourceforge.net/vim-patches.html
> It will be easier to test this patch and pyclewn 1.1 can now run with
> Vim in a console.
>
The documentation at
http://pyclewn.sourceforge.net/vim-patches.html
has been updated with using Vim Mercurial repository instead of
a Mercurial repository built from subversion.
Xavier
Bram Moolenaar
Xavier de Gaye wrote:
> I have setup a Mercurial Queues patch at
> http://pyclewn.sourceforge.net/vim-patches.html
> It will be easier to test this patch and pyclewn 1.1 can now run with
> Vim in a console.
>
> The major change from the patch I sent last April, is that netbeans
> version has been increased to "2.5".
>
> Using Mercurial Queues for Vim patches, brings the following advantages:
>
> * the patch can be kept in sync with Vim development source tree
> * it is easy to test the patch with Vim development source tree
> * at any time, one can remove the patch with 'hg qpop'
>
> I will keep this patch in sync with Vim development source tree.
I had a brief look at the patch. It changes a lot of code, I'll need to
take more time to see what this actually changes.
You move the code to connect for different GUI versions to another
place, away from the disconnect code. I don't see a reason for this.
Why not keep it as it was?
--
If evolution theories are correct, humans will soon grow a third
hand for operating the mouse.
Xavier de Gaye
>
> You move the code to connect for different GUI versions to another
> place, away from the disconnect code. I don't see a reason for this.
> Why not keep it as it was?
>
Hi Bram,
netbeans_startup_done() has been split in two parts:
* netbeans_connect()
* a new function called netbeans_gui_register()
This is needed so that when the user is running netbeans in a vim
console, then netbeans is still available after the ":gui" command
is run and vim switches to the gui interface (requiring only a call
to netbeans_gui_register(), the socket being already connected).
I have put the code of netbeans_gui_register() close to
netbeans_startup_done() because they are related. But
netbeans_gui_register() can be moved up close to the disconnect code.
Xavier
Bram Moolenaar
Xavier de Gaye wrote:
I find it most important to keep the code for a specific GUI together,
if it's not too much hassle. So we have a block of code that's the
GUI-specific implementation of the netbeans interface. If one would add
another GUI most of the change would be to add another block here,
instead of making changes all over the place.
--
A computer without Windows is like a fish without a bicycle.