We just had a very productive meeting on IRC. The results in short:
1) name "vimplugin"
2) hosting
Use sf.net's services, including svn, mailing list and tracking
system.
3) namespace "org.vimplugin"
4) Code conventions: Use Eclipse's builtin formatting.
5) Things to do:
Create a branch in vimplugin's repository and importing all code in
eeedit into that branch. Then start off developing eeedits current
state (respective change of namespace)
The full protocol is attached below.
Sebastian.
-----
You are now known as bastl
--> edyfox (n=edw...@203.86.61.98) has joined #eevp
<edyfox> Now waiting for David. He didn't accept my invitation. So
I'm not sure whether he will arrive on time.
<bastl> hi edyfox
<edyfox> :-)
<bastl> finally we have good chance to hold this meeting
never did something like this before, are there any conventions?
<edyfox> I don't know. I'm not familiar with IRC.
<bastl> ok :-) I only use it from time to time to get immediate suppot
from developers ...
not that fair, but fast ...
<edyfox> Oh, in such situation I always use mailing lisit.
So I know only a few IRC commands.
Such as /pat /me.
/pat /me
Seems not work...
* bastl knows at least hot use /me
<bastl> dnot know /pat
you are vim commiter right?
<edyfox> No, I'm doing the supporting work only.
<bastl> that means?
docs and the like?
<edyfox> Not docs, but to keep the repository running properly.
<bastl> i c
<edyfox> All patches are sent out by Bram himself.
<bastl> I always wondered how vim-development works.
just send sth to bram and he commits it?
thats a lot of work ...
<edyfox> Yes, every patch should be reviewed by Bram.
I don't like this developing model.
<bastl> yes, i wonder what happens if bram disappears out of some
reason ... (accident or so)
<edyfox> So I just suggested that we can review patches for each
other. We don't need a central controller.
<bastl> hmm. interesting, but since im no c-programmer at all, ill
never even try to code something for vim.
no david ...
<edyfox> Do you have any other IM which could reach him?
<bastl> perhaps i a very old mail, let me see
MSN: ned...@hotmail.com
<edyfox> He said that this time is OK for him 21 hours ago...
<bastl> But i have no MSN account...
ill send a mail privately ...
perhaops i forgot.
he*
<edyfox> I added his MSN. No response yet.
<bastl> sent a mail, we have to wait.
<edyfox> OK. David is from Australia?
--> DavidT (n=ned...@c220-239-10-165.belrs4.nsw.optusnet.com.au) has
joined #eevp
<DavidT> ahhh hello all
sorry for being late, havent used IRC for ages and freenode has
changed its address since i last used it
<edyfox> OK~
<DavidT> are we waiting on anyone else still? not sure if nageshwar is
planning on turning up
<edyfox> What's the current situation of the two projects?
<bastl> vimplugin is dormant, the published version is the terminal
one.
<DavidT> well, not much work has being happening on our latley
<bastl> vimclient (the one, david and nageshqwar built up upon,) is
just a experimantal branch
<DavidT> ive been busy with full time work and also its easy to be
distracted with trying to merge our two projects together
<bastl> same here and for everyone of us i guess :-)
<DavidT> yeah true there are many different ways we could go about
trying to get vim into eclipse, ours is just one approach
<bastl> but it rocks :-)
<edyfox> to davidt: OK. But IIRC you once said that you had a
solution to the Eclipse tab embedding issue. Have you submit your
changes?
<DavidT> a our SoC project was more aimed actually at investigating
ways to integrate vim and eclipse, rather then actually getting that
part done
<bastl> edyfox: it works great ...
<DavidT> the tab issue can be solved quite easily in the sense thats
its very possible
i don't think it would take too much code either
<bastl> ah, sorry misunderstood you ...
<DavidT> its just a question of style i guess since there are a few
different ways you could solve it
<edyfox> OK. But it's in high priority.
<DavidT> yes it is
there is an easy solution to it which will take 1 minute and a new
release
which ill probably do i guess until a better solution is ready
anyway im not sure if this is heaps relevant right now
<edyfox> DavidT: What is it?
<DavidT> well just quickly, we can launch vim in two ways
<bastl> David: right.
<edyfox> DavidT: I think I can do some merging work. But I haven't
looked at vimplugin yet.
<DavidT> one is to use the 'Default Vim instance'
<bastl> i have three topics for this meeting:
1) name, 2) hosting 3) java namespace
<DavidT> edyfox: ill talk to you about this after
<edyfox> OK, then let's focus on these three topics.
<DavidT> name: I'm happy to go with vimplugin
eeedit is pretty vauge
<bastl> for the name, i want vim in eclipse.
ok, 1) ysolved :-)
<DavidT> so wait though
<bastl> nice
<DavidT> what name?
<bastl> sorry, wanted to explain why i want "vimplugin"
and not eesomething
<DavidT> ook
so the name is then: "vimplugin" ?
<bastl> :-)
yes. i have the domain vimplugin.org btw
<DavidT> ok cool
<bastl> in case we wanna leave sf.net
<DavidT> okay, thats always useful
<edyfox> Leave sf? Do you mean hosting our own Trac site?
<bastl> i'd like to use trac too, but we would need a host for that ..
was davids proposal
<DavidT> are we sure we cant use trac with SF
<bastl> David: we cant
trac needs svn server on the same host
not possible with sf.net
<edyfox> That's the second issue. Let's finish the first issue before
discussing that.
<DavidT> so people who are using trac on SF (e.g pidgin)
<bastl> edyfox: the name? are you not ok with vimplugin ?
<edyfox> I think both "vim" and "plugin" are OK to me. But I don't
think this name makes sense to Eclipse.
<DavidT> yeah i agree with you there
<edyfox> In fact EEEdit doesn't make sense, either.
<DavidT> im happy with vimplugin over eeedit
but i would like to perhaps think of a better name then both
<bastl> i think its a tool for vimmers who need to use eclipse
<edyfox> Yes, I hope it possible for us to give out a proper name with
10 minutes.
<bastl> not sure. im completely ok with vimplugin
of course it could be misunderstodd since vim has its own plugins ...
is that the issue?
<DavidT> yeah more that its pretty generic
<edyfox> I hope to have some fragments referring to Eclipse in the
name. Such as Subclipse. We can easily understand that the project
is about subversion and eclipse.
<DavidT> vim plugin could be a plugin for anything
<bastl> so you want to propose vimclipse ?
very nice
<edyfox> Maybe something like that.
I once composed viclipse. But it seems that it doesn't look pretty.
<DavidT> i prefer it over vimplugin
but
it doesn't flow heaps well
<edyfox> vimclipse doesn't pronouced nicely. :-(
<DavidT> perhaps a play on Vi and Vim
i.e ViE or Vime
<edyfox> ViE looks like viemu, which is Vim Emulator for Visual
Studio.
<DavidT> haha i see, someone beat us to it
<bastl> edyfox: i like pronounciation
David: right there is viclipse
do we really need a new name?
<edyfox> Well, then just keep the current name. As any good names are
already occupied
<bastl> ok, we can ask on the lists lateron if they wish a new
name ...
so 2), hosting then?
<DavidT> so do pidgin and others who are on SF but use trac
have their own hosting elsewhere?
<bastl> let me see ...
seems they only host mailinglists on sf.net
no scm
<edyfox> OK, so it's impossible to use Trac with SF's SCM.
<DavidT> dan
*dang
well hosting is just SF vs GC then i guess
<edyfox> So how about keep using SF's all services, such as issue
tracking system, SF?
I think SF's tracking system is much better than GC's.
<bastl> edyfox: im not happy with sf.nets bugtracker
<edyfox> bastl: What's wrong with it?
<bastl> but i never used it intensively ...
strange interface, webbased ...
<DavidT> im not a fan of SF dev tools myself much either
but im happy to go with SF over GC still
<bastl> but in the current situation, i would stick to it...
we can always switch ...
<DavidT> yes but it would be best if we didnt have to
<bastl> right.
<DavidT> that is a good thing with having vimplugin.org though
since we can then easily redirect that if we do change
<bastl> i looked for free trac hosting, but there seems to be nothing
good: http://tinyurl.com/36g3k6
would any of us take the burden of doing the hosting himself ?
(i had the technical infrastucture, but fear the workload)
<DavidT> i thought of it
<edyfox> In fact it's not quite difficult to set up a Trac-based web
site.
<DavidT> but my hosting infastructure is an old P166Mhz
works great for my own small weserver and SCM
but not for something of this size
<bastl> I have a vServer. that would be ok, but i dont want to
administer it for such custumized things..
So i propose to make vimplugin.org the main page (that means turn off
vimplugin.sf.net) and stay at sf.net for the next months at least.
we can rethink at the end of the year until we have more
experience ...
<DavidT> yeah im happy with that, id rather just get going asap
<bastl> rright
<DavidT> and given the scale of the project
<edyfox> OK.
<DavidT> the tracker and other tools won't be a big issue anyway
<bastl> ok. consensus
<edyfox> So, the result for the 2nd issue is: keep hosting at sf.net,
and using sf.net's tracking system.
Right?
<DavidT> yes
a final issue with hosting
is mailing lists
<edyfox> OK, now the 3rd issue.
<bastl> david: why?
<DavidT> do we want to go with Google groups, or use SF mailing lists?
<edyfox> I don't like SF's mailing list.
<bastl> i must say i made no good experience with GC.
<edyfox> I think Google Groups is the best mailing list.
<bastl> duplicate mails, bad wrapping ...
hm
<DavidT> ive always had very good experiences with GG's
but i dont really mind much since I just use an email client and
never the web front end
<edyfox> I didn't see any duplicated mails. The wrapping... I always
wrap my mail with GVim, so the Gmail's bad wrapping never disturbs me.
<DavidT> so SF or GG are much the same fo rme
<bastl> again, we can can change things, but i would do that only if
there is a lot of pressure from the community ...
<edyfox> So we keep using the SF's mailing list?
<bastl> and another point is to keep infrastructure together. if we
use sf.net for issues and hostingm why not for mails?
edyfox: i would say so.
<edyfox> Well, OK.
<bastl> ok, david?
<DavidT> yes fine by me
3) java namespace is solved pretty easily i think
<edyfox> GC doesn't provide any built-in mailing list. In GC we also
use Google Groups, which is *external* to GC, although in some sense
"internal" to Google.
I want to expand the 3rd issue.
Not only about the namespaces, but also the code conversions.
<bastl> ok?
<DavidT> what do you mean by code conversions?
<edyfox> Such as the maximum length of lines, the brackets positions,
line wrapping styles, etc.
<DavidT> ok
conventions
<bastl> Ctrl-Shift F
sorry. It's eclipse shortcut
for autoformat
i dont care to much on that topic ...
though it should be consistent
but im ok with tabs spaces, indents what ever.
<edyfox> I seldom use Eclipse. But I think we can choose a nice
convertion scheme from Eclipse and I can learn from it myself.
<DavidT> yeah i have my own preference but as long as well are all
consitent i dont mind
<bastl> BTW: there is a java codeconvention by sun
<edyfox> As there are many different convertions in Eclipse.
<DavidT> I think it comes with 2 pretty much
Eclipse Convention, and Sun Convention
<edyfox> bastl: Yes, but not enough. Sun's convertion doesn't cover
the bracket position issue.
<bastl> ok...
<edyfox> class A {
}
or
class A
{
<bastl> i prefer first one
<DavidT> first one
with Java I prefer bracketing in all cases to be on same line
<edyfox> It's not easy to figure out all convertions this way. So I
just suggest that we choose a built-in convertion from Eclipse and we
can learn from it later.
<bastl> edyfox: ok.
i gtg to lunch soon, could we postpone that?
let me elaborate on java namespace
<edyfox> OK. I'm leaving for supper, too.
<bastl> i chose org.vim.vimplugin as a "contribution" to vim.
the correct way would be org.vimplugin
but again, this is a minor issue
<DavidT> i prefer org.vimplugin since java packages are long enough
without putting an extra vim in there
<bastl> ok.
im fine with that
<edyfox> Agree with DavidT.
<bastl> ok.
<DavidT> okay just quickly on Code Conventions
<bastl> last point: should we post a log of this chat somewhere?
<DavidT> i just use the builtin Eclipse Formatter
<bastl> DavidT: me too.
<DavidT> so the current code for eeedit is done in that style
so i think we just use this as a starting point
<edyfox> I'm reading that conversion...
<DavidT> yeah
<bastl> if we change something we can put the "template" into svn. its
configurable
<DavidT> we probably should post a log of the chat somewhere
<edyfox> Yeah! I'm glad that this conversion doesn't indent "case"
statement.
<DavidT> there are two other developers out there who arent here
<edyfox> convertion. Sorry...
<DavidT> its cool
<bastl> fine. ill post that to the two mailinglists.
and now im going to lunch.
thanks for that highly productive chat :-)
<DavidT> yeah im off to dinner and some sleep
indeed, talk to you all soon
i guess though
<edyfox> Leaving for supper, too~
<DavidT> bastl you will start pulling the code across into SF?
<edyfox> Could you grant me the corresponding access to the SF's
project?
<bastl> David: yes
<DavidT> okay cool
> We just had a very productive meeting on IRC. The results in short:
Great to hear you are all cooperating and making progress. I don't have
time to keep track of what you are all doing, especially on the Eclipse
side. Do let me know of any changes that are needed on the Vim side.
- Bram
--
I think that you'll agree that engineers are very effective in their social
interactions. It's the "normal" people who are nuts.
(Scott Adams - The Dilbert principle)
/// 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 ///
>
> 5) Things to do:
> Create a branch in vimplugin's repository and importing all code in
> eeedit into that branch. Then start off developing eeedits current
> state (respective change of namespace)
>
why cant we use eeedit current source as main trunk. I think no part
of previous vimplugin code is suitable to merge into eeedit code. They
are following completely different types of implementations. Since all
the people prefer gvim to emulated console ( at least, on eclipse
platform), lets directly use eeedit code as trunk. If you decided this
for some reason, please let me know what that is.
--
Thanks,
Nageshwar M.
--
Best Regards,
Nageshwar M.