vimplugin-devel — list for vimplugin development

[vimplugin-devel] howto build and run eclim

[Sebastian M. <seb...@un...>]

Am Tue, 16 Oct 2007 18:28:40 -0700
schrieb "Eric Van Dewoestine" <erv...@gm...>:

> Are you referring to how to build it (compile, deploy, etc.) or are
> you asking about the architecture?

I just want to compile and run it: how do I have to configure project
settings (e.g. dependency of formic), howto build it etc ...

Things are a bit different in contrast to standard plugins since you
define a whole new (headless) eclipse-app.

BTW great to have you on the list ... :-)

Seb.

Re: [vimplugin-devel] SVN repository *EXTREMELY* slow

[Eric V. D. <erv...@gm...>]

Are you referring to how to build it (compile, deploy, etc.) or are
you asking about the architecture?

On 10/16/07, Sebastian Menge <s....@gm...> wrote:
> Am Tue, 16 Oct 2007 17:21:28 -0700 schrieb Eric Van Dewoestine:
>
> > Regarding eclim, now that I'm on the mailing list I can answer any
> > specific questions you guys may have.
> >
> >> Are there any notes how the project is being built ?
>
> hehe, this one was meant for you :-)
>
> Seb.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> vimplugin-devel mailing list
> vim...@li...
> https://lists.sourceforge.net/lists/listinfo/vimplugin-devel
>


-- 
eric

Re: [vimplugin-devel] SVN repository *EXTREMELY* slow

[Sebastian M. <s....@gm...>]

Am Tue, 16 Oct 2007 17:21:28 -0700 schrieb Eric Van Dewoestine:

> Regarding eclim, now that I'm on the mailing list I can answer any
> specific questions you guys may have.
> 
>> Are there any notes how the project is being built ?

hehe, this one was meant for you :-)

Seb.

Re: [vimplugin-devel] SVN repository *EXTREMELY* slow

[Eric V. D. <erv...@gm...>]

Regarding eclim, now that I'm on the mailing list I can answer any
specific questions you guys may have.

On 10/16/07, Sebastian Menge <s....@gm...> wrote:
> Am Tue, 16 Oct 2007 19:36:24 +0200 schrieb Martin Krischik:
>
> > I think it's a cool idea.
>
> Absolutely. It is definitely worth looking into. Eclipse
> codecompletion inside an embedded vim would be exactly what we all are
> looking for, I guess :-)
>
> I have checked out eclim myself to try some experiments on it, but did
> not manage to get it run by now ;-) Are there any notes how the
> project is being built ?
>
>
> > Well, in the project I am Admin I see these things rather relaxed.
>
> Whereever ppl come together to build something up, there are rules
> (call it laws, good/bad behavior, etiquette, whatever): some are
> implicite, some not. If conflicts arise, the conclusion should be a
> new rule such that ppl learn to work together constructively.
>
> The classical example is quoting in mailing lists: If the majority of
> ppl are annoyed by a certain kind of quoting they will express that
> someday. Then the community will decide what will be best. This is in
> fact a kind of democratic decision making.
>
> The SVN-Repository is our main development spot. We need to keep it
> tidy and in good order.  Edward complained that it is not in good
> order and I must say that my personal opinion (which is just one of
> many) is along Edwards. The mere comparison of directory sizes [1]
> tells me that there is something out of balance.
>
> If there is no better way than copying a whole other repository, I (again
> myself) would at least ask whether other team-members have objections,
> before importing something that is 30 times as large as the main trunk.
> But hopefully the others will come up with better ways.
>
> Now that it has happened, we should look forward for ways how to deal
> with it. I would propose the following (since I _really_ like the
> idea to use eclims features in our context, please keep it going!):
>
>   * we should develop experiments locally.
>   * when something useful comes out (e.g. a non-headless eclim server,
>     as a first step), create patches (which is fairly easy with eclipse:
>     "Team|Create Patches" in the context menu of a project)
>   * publish patches here and to eclims developer(s)
>   * discuss patches a bit
>   * if the patches look promising but changes are too big, create branch
>     for it
>
> So the general "rule" I would like to extract from this is simple:
>
>   "Before doing any large scale operations that potentially affect
>   others, discuss/ask about it on the mailing list."
>
> But as I said, this is a free project, and the other members should
> say what they think (e.g. it could be an option to say: Everything
> under "branches" can be used at free will.).
>
> Best regards, Sebastian.
>
> [1] some directory sizes:
> trunk: 1,9MB
> tags: 7,6MB (some old releases)
> branches/eeedit 1,5MB
> branches/eeedit-import 5,0MB
> branches/gvimplguin 1,8MB
> branches/vimclient 1,6 MB
> branches/eclimplguin 61MB (21 formic, 38 eclim)
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> vimplugin-devel mailing list
> vim...@li...
> https://lists.sourceforge.net/lists/listinfo/vimplugin-devel
>


-- 
eric

Re: [vimplugin-devel] SVN repository *EXTREMELY* slow

[Sebastian M. <s....@gm...>]

Am Tue, 16 Oct 2007 19:36:24 +0200 schrieb Martin Krischik:

> I think it's a cool idea.

Absolutely. It is definitely worth looking into. Eclipse
codecompletion inside an embedded vim would be exactly what we all are
looking for, I guess :-)

I have checked out eclim myself to try some experiments on it, but did
not manage to get it run by now ;-) Are there any notes how the
project is being built ?


> Well, in the project I am Admin I see these things rather relaxed.

Whereever ppl come together to build something up, there are rules
(call it laws, good/bad behavior, etiquette, whatever): some are
implicite, some not. If conflicts arise, the conclusion should be a
new rule such that ppl learn to work together constructively.

The classical example is quoting in mailing lists: If the majority of
ppl are annoyed by a certain kind of quoting they will express that
someday. Then the community will decide what will be best. This is in
fact a kind of democratic decision making.

The SVN-Repository is our main development spot. We need to keep it
tidy and in good order.  Edward complained that it is not in good
order and I must say that my personal opinion (which is just one of
many) is along Edwards. The mere comparison of directory sizes [1]
tells me that there is something out of balance.

If there is no better way than copying a whole other repository, I (again 
myself) would at least ask whether other team-members have objections, 
before importing something that is 30 times as large as the main trunk. 
But hopefully the others will come up with better ways.

Now that it has happened, we should look forward for ways how to deal
with it. I would propose the following (since I _really_ like the
idea to use eclims features in our context, please keep it going!):

  * we should develop experiments locally.
  * when something useful comes out (e.g. a non-headless eclim server, 
    as a first step), create patches (which is fairly easy with eclipse:
    "Team|Create Patches" in the context menu of a project)
  * publish patches here and to eclims developer(s) 
  * discuss patches a bit
  * if the patches look promising but changes are too big, create branch 
    for it

So the general "rule" I would like to extract from this is simple:

  "Before doing any large scale operations that potentially affect 
  others, discuss/ask about it on the mailing list."

But as I said, this is a free project, and the other members should
say what they think (e.g. it could be an option to say: Everything
under "branches" can be used at free will.).

Best regards, Sebastian.

[1] some directory sizes:
trunk: 1,9MB
tags: 7,6MB (some old releases)
branches/eeedit 1,5MB
branches/eeedit-import 5,0MB
branches/gvimplguin 1,8MB
branches/vimclient 1,6 MB
branches/eclimplguin 61MB (21 formic, 38 eclim)

Re: [vimplugin-devel] Just a test

[Rashmi R. <ras...@gm...>]

Thank you John, I wasn't aware that my message was received.

When I posted the first time, I wasn't subscribed to the list, so I
thought it didn't reach, then I posted it again after subscribing to
the list.

>From my experience with lists, if I posted the message when I wasn't
subscribed the message would bounce back.

I apologize for the double posts, I just replied to an offline message
I received from Sebastian he helped me with my problem.

Regards
-Rashmi

On 10/16/07, John Beckett <joh...@gm...> wrote:
> Rashmi Rubdi wrote:
> > I sent an e-mail in the past few days with
> > NullPointerException in the subject line.
> > I just wanted to check if anyone on this mailing list received it.
>
> Yes - it was received. You can see the mail and a reply at:
>
> http://sourceforge.net/mailarchive/forum.php?forum_name=vimplugin-devel
>
> John
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> vimplugin-devel mailing list
> vim...@li...
> https://lists.sourceforge.net/lists/listinfo/vimplugin-devel
>

Re: [vimplugin-devel] Just a test

[John B. <joh...@gm...>]

Rashmi Rubdi wrote:
> I sent an e-mail in the past few days with 
> NullPointerException in the subject line.
> I just wanted to check if anyone on this mailing list received it.

Yes - it was received. You can see the mail and a reply at:

http://sourceforge.net/mailarchive/forum.php?forum_name=vimplugin-devel

John

[vimplugin-devel] Just a test

[Rashmi R. <ras...@gm...>]

Hello,

I sent an e-mail in the past few days with NullPointerException in the
subject line.

I just wanted to check if anyone on this mailing list received it.

Please let me know -- offline is fine as well.

-Thank you
Rashmi

Re: [vimplugin-devel] SVN repository *EXTREMELY* slow

[Martin K. <kri...@us...>]

Am Montag 15 Oktober 2007 schrieb Sebastian Menge:

> Hi Edward,
>
> I'm sorry you have problems with the repo.
>
> Am Mon, 15 Oct 2007 16:55:38 +0800 schrieb Edward L. Fox:
>
> Martin committed a lot of things into a branch called eclimplugin.
>
> Martin, could you explain your plan to us, and perhaps figure out a
> better way?

You might know about the eclim project [1]. It does the opposite of what we=
 do=20
here: You use Vim to remote controll an Eclipse server. That is: Vim is the=
=20
master and Eclipse is the slave.

This has the advantage that Eclipse functions are available in=20
Vim. ":ProjectSettings" for example would open the projects setting's in vi=
m.=20
But the killer features are integration of code completion, code correction=
=20
and quickfix. I might have missed something - but I have not seen anything =
in=20
that direction in our project.

However, Eclim has an all or nothing approach: You don't have Ecliplse at a=
ll=20
visible and any feature not yet communicated is not available. Now I think=
=20
that is a rather drastic approach.

Now my idea is to start the Eclim server by gvimplugin when the first GVim =
is=20
opened. The freshly started GVim can then call back and make all the nice=20
Eclim features available.

I think it's a cool idea.=20

> In general I would suggest to d
> 1) do some local experiments and=20

Without off site backup? That's one of the reasons I use SourceForge: If=20
something bad is happening to either me or my computer the work is not lost.

> 2) publish  a working prototype to a private website and

Well, thought that is one of the things for what branches are for: Keeping =
a=20
experiments separate from the rest of team until they are ready.

> 3) ask the other developers=20
> whether or how it could be merged into the main trunk...  (perhaps it's
> worth a new project ..)

Right on. Only a separate project would not work all that well, for the pla=
n=20
to work one need both parts.

> Would it perhaps be clever to develop some "social rules" how we want to
> run the project? Any proposals?

Well, in the project I am Admin I see these things rather relaxed. But then=
 in=20
none of the other projects we have a commit mailing list or a team member w=
ho=20
need to mirror the whole repository...

Martin

[1] http://eclim.sourceforge.net/

=2D-=20
Martin Krischik
mailto://krischik@users.sourceforge.net

[vimplugin-devel] NullPointerException when opening a file with Vim in Eclipse

[Rashmi R. <ras...@gm...>]

Hello Everyone,

I'm trying out ViMPlugin for the first time. Thank you so much for this plugin.

I'm having a little problem. I'm getting a NullPointerException when I
try to open a file with ViM in Eclipse.

Here are the steps I took to open a file:

1) Opened the Resource or the Java perspective.
2) Right clicked on a .txt file in the Project Explorer and clicked on
"Open with ViM"

At this point I get a NullPointerException in Eclipse. Eclipse didn't
show a full stack trace when I clicked on the Details button.

My environment details:

1) ViM Plugin version 0.3.1

2) Eclipse Platform
Version: 3.3.0
Build id: M20070921-1145

3) Java(TM) SE Runtime Environment (build 1.6.0_01-b06)

4) OS: Windows XP

I've followed the installation instructions mentioned here:
http://vimplugin.sourceforge.net/wiki/pmwiki.php?n=Community.Installation

I'm relatively new to Eclipse, but can find my way around it, however
I don't know how to get the full stack trace.

Please let me know how to get the stack trace in Eclipse , or if I'm
missing anything or doing anything incorrectly.

-Regards
Rashmi

Re: [vimplugin-devel] new release and mailing list

[Sebastian M. <seb...@un...>]

Am Mon, 15 Oct 2007 08:21:11 -0500
schrieb "Steven Timpson" <ste...@fe...>:

> Yes I can open the webpage in a browser and download the .jar file.
> Now I tried placing the jar file in the references/plugins dir with no
> effect.  Can seem to figure out how to load it to eclipse.

Steve: Did you try the feature jar or the plugin jar? Can you install
other plugins via an update site (perhaps a network problem) What OS,
Java, Eclipse version do you use? Did you try to clean up rests from
old installation attempts? What does the plugin-registry say?
(Window>Show View>Runtime PDE>Plugin Registry)

OK, could someone but me please confirm whether the update site is
working?

I can't see if this is a configuration problem of Steve or a bug in
the update site.

Thanks, Sebastian.

Re: [vimplugin-devel] NullPointerException when opening a file with Vim in Eclipse

[Sebastian M. <seb...@un...>]

Hey Nageshwar,

could you please try to quote the mails you reply-to? There were a lot
of flamewars about the issue whether the quote should be above the
reply or beneath, but most ppl agree that there should be a quote. ;-)

Here is a link that describes the issue well:
http://www.massey.ac.nz/~tameyer/writing/quoting.html

Please take it as a good advice as i'm sure many ppl (also on
other forums/lists) think like that ...

Am Mon, 15 Oct 2007 22:19:53 +0530
schrieb Nageshwar <nag...@st...>:

>     did you specify the path to the gvim executable. If not, please go
> to preferences window and  give the path to the executable and try. To
> embed the vim into eclipse editor tab, you need to have gvim 7.1.091
> or greater.

This is an issue: If the gvim executable is not present, vimplugin
should give warning/error but should not crash ... the NPE should be
caught and dealt with accordingly (MessageBox or similar ...)

Best regards, Sebastian.

Re: [vimplugin-devel] SVN repository *EXTREMELY* slow

[Sebastian M. <s....@gm...>]

Hi Edward,

I'm sorry you have problems with the repo.

Am Mon, 15 Oct 2007 16:55:38 +0800 schrieb Edward L. Fox:

> I had begun to mirror the SVN repository to my local SVK repository
> since the day before yesterday.  But up till now, the mirroring is still
> in progress, at revision 141.  I have to admit that the SVN service on
> SF.net is a bit too *slow* to me.  I also tried to mirror the repository
> from the latest revision, by passing all the former revisions, but it
> was still quite slow.

Is it slow is it too much data? One only needs the trunk ... no branches 
or tags ... I have absolutely no performance probs here. Why do you need 
to mirror the whole repo?

> I briefly browsed around the repository and found that a lot of
> third-party jar archives, generated binary files and many sorts of
> things was mistakenly committed into the repository.  So I just think,
> is there any way to erase all the history from the repository and
> re-create a brand new clean repository?  I really can't start my work in
> current situation.

Martin committed a lot of things into a branch called eclimplugin. 

Martin, could you explain your plan to us, and perhaps figure out a 
better way? 

In general I would suggest to 1) do some local experiments and 2) publish 
a working prototype to a private website and 3) ask the other developers 
whether or how it could be merged into the main trunk...  (perhaps it's 
worth a new project ..)
 
Would it perhaps be clever to develop some "social rules" how we want to 
run the project? Any proposals?

Sebastian.

Re: [vimplugin-devel] SVN repository *EXTREMELY* slow

[Martin K. <kri...@us...>]

Am Montag 15 Oktober 2007 schrieb Edward L. Fox:

> I had begun to mirror the SVN repository to my local SVK repository
> since the day before yesterday.  But up till now, the mirroring is
> still in progress, at revision 141.  I have to admit that the SVN
> service on SF.net is a bit too *slow* to me.  I also tried to mirror
> the repository from the latest revision, by passing all the former
> revisions, but it was still quite slow.

Why would you want to mirror the whole repository? To me that seems to be a=
n=20
overkill.

> I briefly browsed around the repository and found that a lot of
> third-party jar archives, generated binary files and many sorts of
> things was mistakenly committed into the repository.  So I just think,
> is there any way to erase all the history from the repository and
> re-create a brand new clean repository?  I really can't start my work
> in current situation.

Maybe - but it seems a lot of work. Also we loose other interesting options=
=2E I=20
for once backup my PMWiki's into SourceForge - which too take up space.

Martin
=2D-=20
Martin Krischik
mailto://krischik@users.sourceforge.net

Re: [vimplugin-devel] NullPointerException when opening a file with Vim in Eclipse

[Nageshwar <nag...@st...>]

Hey,
    did you specify the path to the gvim executable. If not, please go
to preferences window and  give the path to the executable and try. To
embed the vim into eclipse editor tab, you need to have gvim 7.1.091
or greater.

-- 
Best Regards,
Nageshwar M.

[vimplugin-devel] NullPointerException when opening a file with Vim in Eclipse

[Rashmi R. <ras...@gm...>]

Hello Everyone,

I'm trying out ViMPlugin for the first time. Thank you so much for this plugin.

The only problem is that, I'm getting a NullPointerException when I
try to open a file with ViM in Eclipse.

Here are the steps I took to open a file:

1) Opened the Resource or the Java perspective.
2) Right clicked on a .txt file and clicked on "Open with ViM"

At this point I get a NullPointerException in Eclipse. Eclipse didn't
show a full stack trace when I clicked on the Details button.

My environment details:

1) ViM Plugin version 0.3.1

2) Eclipse Platform
Version: 3.3.0
Build id: M20070921-1145

3) Java(TM) SE Runtime Environment (build 1.6.0_01-b06)

4) OS: Windows XP

I've followed the installation instructions mentioned here:
http://vimplugin.sourceforge.net/wiki/pmwiki.php?n=Community.Installation

I'm relatively new to Eclipse, but can find my way around it, however
I don't know how to get the full stack trace.

Please let me know how to get the stack trace in Eclipse , or if I'm
missing anything or doing anything incorrectly.

-Regards
Rashmi

Re: [vimplugin-devel] new release and mailing list

[Steven T. <ste...@fe...>]

Yes I can open the webpage in a browser and download the .jar file.
Now I tried placing the jar file in the references/plugins dir with no
effect.  Can seem to figure out how to load it to eclipse.

Steve

-----Original Message-----
From: vim...@li...
[mailto:vim...@li...] On Behalf Of
Sebastian Menge
Sent: Friday, October 12, 2007 5:34 PM
To: vim...@li...
Subject: Re: [vimplugin-devel] new release and mailing list

Am Fri, 12 Oct 2007 13:49:28 -0500
schrieb "Steven Timpson" <ste...@fe...>:

> Still not working.  Below is the error that I am getting.
>=20
> Network connection problems encountered during search.
>   Unable to access "http://vimplugin.sf.net/update/site.xml".
>     Error parsing site stream. [Premature end of file.]
>     Premature end of file.
>     Error parsing site stream. [Premature end of file.]
>     Premature end of file.

Can you open it in the browser?

Seb.


------------------------------------------------------------------------
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
vimplugin-devel mailing list
vim...@li...
https://lists.sourceforge.net/lists/listinfo/vimplugin-devel

Re: [vimplugin-devel] [eeedit-dev] Issue 14 in eeedit: --windowid not --socketid on windows.

[Sebastian M. <seb...@un...>]

Am Sun, 14 Oct 2007 20:33:06 +0000 (UTC)
schrieb Sebastian Menge <s....@gm...>:

> >> On windows the command line option for vim to embed it into an
> >> existing window is --windowid. We try to use the option --socketid
> >> which is correct on Linux, but not windows.
> >>
> >> We should either change our code or submit a patch to vim to
> >> change the option to --socketid since it works the same as the
> >> linux --socketid option.
> > 
> > No just change the plugin code. Bram asked me to change the
> > commandline argument socketid to windowid. 

Fixed. Windows users with gvim >= 7.1.091 can use embedding now.

S.

[vimplugin-devel] SVN repository *EXTREMELY* slow

[Edward L. F. <ed...@gm...>]

Hi all,

I had begun to mirror the SVN repository to my local SVK repository
since the day before yesterday.  But up till now, the mirroring is
still in progress, at revision 141.  I have to admit that the SVN
service on SF.net is a bit too *slow* to me.  I also tried to mirror
the repository from the latest revision, by passing all the former
revisions, but it was still quite slow.

I briefly browsed around the repository and found that a lot of
third-party jar archives, generated binary files and many sorts of
things was mistakenly committed into the repository.  So I just think,
is there any way to erase all the history from the repository and
re-create a brand new clean repository?  I really can't start my work
in current situation.


Best regards,


Edward Fox

Re: [vimplugin-devel] VimEditor and VimEditorNewWindow

[Nageshwar <nag...@st...>]

Hi Sebastian,

>
> Could't we embed the _same_ gvim using "--socketid" in the different
> eclipse-editor-tabs all the time?  Then when the eclipse tab is
> changed, or a new editor is opened, we only create a new buffer in
> vim, select that buffer and we are done. The user should not notice
> what is going on behind the scenes (unless he did :buffers or
> similar). When Embedding is unchecked, we could use tabs instead.
>
We followed the same idea for standalone vim instance. But I didn't
check whether that is working or not. I don't think that the
"embedding same window multiple times" will work. Each window contains
only a single parent. As far as I know, the vim instance will appear
in the latest eclipse editor. I searched the same on the net but
couldn't find any relevant results. Anyway once please check it. Just
enable the embed vim option and open files in standalone vim.

> That would give a cleaner design (one editor class instead of three,
> where two of them are two-liners), a cleaner userinterface (only one
> vim-editor in the menu) and at last give a better performance (only
> one gvim running) ..
>
If it doesn't work, we have to modify the protocol and add a new
command to dynamically embed the window. But we can't do that since we
are using netbeans protocol implementation on vim.

> Getting technical: Is there an obvious way to send "normal" vim
> commands to vim? e.g. ":buf <bufid>"
>
This command is there in the protocol. Command is "setDot". We used it
when we get the focus on the eclipse editor tab.


-- 
Best Regards,
Nageshwar M.

Re: [vimplugin-devel] VimEditor and VimEditorNewWindow

[Sebastian M. <seb...@un...>]

Am Sun, 14 Oct 2007 23:38:55 +1000
schrieb "Dave Terei" <dav...@gm...>:

> The two classes aren't about 'opening in an external window' or 'open
> embedded in vim'. That option is indeed as you suggested controlled
> by a setting in the preferences page.
> 
> The two classes are there for either:
> 
> 1) VimEditor class: This class will try to open the file using the
> default Vim instance. If this instance doesn't exist it will be
> created. Using this class multiple files can be opened in one vim
> instance.
> 
> 2) VimEditorNewWindow class: This class will always open a file in a
> new Vim instance which will only contain the one file.
> 

OK, I understand now. And it's explained well in the docs ... I got only
distracted by the name which suggests something else. How about
VimEditorNewInstance instead? 

> Using the second class we can easily embed vim into eclipse since
> each tab will contain its own vim instance. Using the first class
> gives better performance but doesn't embed into eclipse properly at
> the moment. If we use the first class we couldn't use Eclipses tabs,
> but we would be using Vim's tabs.

Could't we embed the _same_ gvim using "--socketid" in the different
eclipse-editor-tabs all the time?  Then when the eclipse tab is
changed, or a new editor is opened, we only create a new buffer in
vim, select that buffer and we are done. The user should not notice
what is going on behind the scenes (unless he did :buffers or
similar). When Embedding is unchecked, we could use tabs instead.

That would give a cleaner design (one editor class instead of three,
where two of them are two-liners), a cleaner userinterface (only one
vim-editor in the menu) and at last give a better performance (only
one gvim running) ..

Getting technical: Is there an obvious way to send "normal" vim
commands to vim? e.g. ":buf <bufid>"

Seb.

Re: [vimplugin-devel] [eeedit-dev] Issue 14 in eeedit: --windowid not --socketid on windows.

[Sebastian M. <s....@gm...>]

Am Sun, 14 Oct 2007 17:58:50 +0530 schrieb Nageshwar M:

>> On windows the command line option for vim to embed it into an existing
>> window is --windowid. We try to use the option --socketid which is
>> correct on Linux, but not windows.
>>
>> We should either change our code or submit a patch to vim to change the
>> option to --socketid since it works the same as the linux --socketid
>> option.
> 
> No just change the plugin code. Bram asked me to change the commandline
> argument socketid to windowid. 

Ah, intersting. Does it mean embedding will work under windows then? That 
will be intersting for a lot of people ....

More interesting is, that we have to support at least win32 and linux.

I seldom use windows, is there someone around who would like to feel 
responsible for testing under win32 ?

Sebastian.

PS: A side note: Can we agree on using plain-text and inline quoting? 
It's sometimes hard to guess what an older thread was about if there are 
no reasonable quotes ...

Re: [vimplugin-devel] VimEditor and VimEditorNewWindow

[Dave T. <dav...@gm...>]

The two classes aren't about 'opening in an external window' or 'open
embedded in vim'. That option is indeed as you suggested controlled by a
setting in the preferences page.

The two classes are there for either:

1) VimEditor class: This class will try to open the file using the default
Vim instance. If this instance doesn't exist it will be created. Using this
class multiple files can be opened in one vim instance.

2) VimEditorNewWindow class: This class will always open a file in a new Vim
instance which will only contain the one file.

Using the second class we can easily embed vim into eclipse since each tab
will contain its own vim instance. Using the first class gives better
performance but doesn't embed into eclipse properly at the moment. If we use
the first class we couldn't use Eclipses tabs, but we would be using Vim's
tabs.

Best Regards,

David Terei.

P.S My email system had a heart attack on the weekend, also not helped by a
misplaced 'rm -r' call by myself. At the moment I'm trying to get it all
fixed up again, hence why I've haven't replied to a fair few emails.

On 10/14/07, Nageshwar M <wha...@gm...> wrote:
>
> Hi,
>
> I read this message on the sf and here is the reason why we
> implemented that way. Starting the Gvim instance is taking a lot of
> time for connection initialization. If the user wants to edit a file
> quickly, he has to wait for the whole procedure. Instead of that he
> can quickly open the file in the existing vim window as another
> buffer. So we have given that option. There is another advanced
> functionality to think about. That is, if there are two opened gvim
> windows and when we right click the file to open, then we will get
> "open in new window", "open in 1st gvim", "open in 2nd gvim" like that
> (similar to context menu provided by vim on windows). This removes the
> redundant code and also gives the user an advanced editing
> environment. If everybody accepts the above idea, then we can continue
> working on that part.
>
> --
> Best Regards,
> Nageshwar M.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> vimplugin-devel mailing list
> vim...@li...
> https://lists.sourceforge.net/lists/listinfo/vimplugin-devel
>

Re: [vimplugin-devel] [eeedit-dev] Issue 14 in eeedit: --windowid not --socketid on windows.

[Nageshwar M <wha...@gm...>]

> Issue 14: --windowid not --socketid on windows.
> http://code.google.com/p/eeedit/issues/detail?id=14
>
> New issue report by dave.terei:
> On windows the command line option for vim to embed it into an existing
> window is --windowid. We try to use the option --socketid which is correct
> on Linux, but not windows.
>
> We should either change our code or submit a patch to vim to change the
> option to --socketid since it works the same as the linux --socketid
> option.

No just change the plugin code. Bram asked me to change the
commandline argument socketid to windowid. Sorry, I forgot to change
the same in eeedit source. And I moved to sourceforge and joined the
vimplugin developers list. David, you too do the same and from now
onwards add the new issues there.

-- 
Best Regards,
Nageshwar M.

[vimplugin-devel] bugtracker

[Sebastian M. <seb...@un...>]

Hi folks

I have cleaned up the bugtracker and added

edyfox, nageshwar and krischik

to the tracker. If you want to get removed please let me know.

Seb.