Hi @all, as most of you know, the (g)vi* packages are a constant subject to suggestions and proposed changes be they stupid or valid. I just like to have some input on two major issues and if we shall pursue them or not: Only vim and gvim are concerne since vi is an entirely different beast now. Here is how the packages are split up: vim: - perl scripting support, since it's small and produces minor overhead - provides runtime files - is mainly intended for command line use where vi is not sufficient gvim: - python (and later again ruby) scripting support for addon scripts - provides X support, vim server support, gtk frontend if invoked with gvim symlink - intended for serious development, I think it's a reasonable assumption that people who do that do not wanna have 80x24 consoles but will have X installed and with X there is a huge likely hood that gtk2 is installed Now, I think that gives a nice and very clear distinction between vim (mainly for console user) and gvim (for developers, but also people who run the vim command in the terminal). Note that after installing the gvim package, the vim command invokes a more powerful, python and X enabled binary. I am getting feature requests, to put it nicely, about enabling python in vim. I'm opposed to that for two reasons: - upon the return of ruby people will pester me about ruby support becuase python is in there and why not ruby .. whine .. blah - I think there is a clear distinction between vim for the console and vim for serious development, and the current layout shows that nicely The arguments about including python are mainly like that: But when I am on this server, or on this very small box, too small to run X and I wanna develop in python etc. I don't think these are valid arguments because they are rare cases. And if it's really true, you can always build a custom python enable smaller vim. Which brings me directly to the second point, the building system. Vim follows a patch based approach which makes the PKGBUILD a fair bit complex. All thes seemed to be fine for the last year but now people seriously pester me that it would be better to build it from cvs/svn and the patch based approach is not good enough anymore because the rebuilds take too long becuase the download takes soooo long. The cvs approach however has a few gotchas IMHO: - first of all I think that's a non issue, becuase Arch is binary based and rebuilding is not really necessary - cvs/svn is behind the patches in vim world - if you rebuild, you rebuild more often, which is supported by the central srccache - I clean up my PKGBUILD directories before rebuilding, I never clean my SRCCACHE so overall I don't benefit from the cvs at all So what I wanna know is, 1. Do we wann have python enabled in vim package (don't forget: as soon as you install the gvim package, you have python in vim and don't use the vim-package binary anymore) 2. Do we wanna have a cvs enabled buildsystem just because upon an initial rebuild the download is faster (It would annoy the hell out of me because as package maintainer I would have to dowload everything everytime) So, I like (g)vim the way it is but I don't wanna be the benevolent I would be okay with 1) if everyone agrees, I know quite few developer use vim. I'm strongly opposed to 2) because it just causes more work and we do have a perfectly usable build system in place. -T