Arch Linux

s/should/would

wrong: s/would/should
sould somebody correct my mistake and delete these comments?
thanks:)

So, this is a bug reported by really frustrated user [;

python is in gvim. Neither the vim nor the gvim executable we provide is actually a binary all are symlinks. when you install gvim, your vim executable magically switches to the more powerful one and calling 'vim' actually invokes a python enabled vim. the vim packages is supposed to stay a little on the leaner side, gvim gets everything. Besides, just adding python to vims dependency almost doubles the executable size.

So install gvim and everything is good.

but sometimes user could want to have full functional vim without X11,
maybe the better idea is to distribute vim enhancments as packages, for example: vim-python vim-ruby?:)

but sometimes user could want to have full functional vim without X11,
maybe the better idea is to distribute vim enhancments as packages, for example: vim-python vim-ruby?:)

@tobias IMO if someone want to use not fully functional vim he could use vi. Why if I want to use vim without all X11 dependencies, I can't use vim but some dysfunctional distribution of it?

vi is too stripped down. it will function as editor for the installer only. The discussion about what interpreter goes into what package is old. There is either the way to make a decision or to provide a million little packages. Non of them is desirable. I one there is not enough flexibility the other makes the process to complex. Arch is all about simplicity. There is no way make everyone happy. The vim architecture and the interpreters has been discussed to death, sorry.

So since yesterday we have to make our own vim(!) pkg's. That's really sad. So what's next? Emacs without elisp interpreter? Keep going... (-.-)

I'm sorry if you see it this way, but I can't follow your arguments: the previous version of vim, which had python support was build with X support which required x libs to be installed, but no X running when using it in the console. The new gvim binary is pretty much the same deal, admittedly with gtk overhead. From that point of view it's just a difference in the name of the installed package. The new vim package packs a smaller version of vim very suitable for admin tasks on the console. If you wanna get serious about vim just install the big package that gives you all. Archlinux never embraced the idea of splitting packages to suit every taste. I for myself could live well with a gvim with no python support, but do like a vim with x as it makes life in terminal windows easier. So for the features I want, I need gvim. It's all about compromises.

vim was in testing for a very long time, preceeding that was a very long discussion here in the bugtracker on how we shall split it up, what to do with vi for core, how to package it so we have to distribute only one runtime etc.

I also need python support for some plugins, and I find the X support quite useless.
But it's indeed debatable, and all about compromises.

If vim had python support, some users could complain they don't want the python dep and that they have to rebuild the package.

So this time there isn't any compromise... What comes to me from perl support if I'm using python? I have to say that I was using also that mouse pointer support. Now I have lost almost everything from my vim package. After installing gvim in vim I still don't have mouse pointer support. So where is the compromise? I really hate using that vim gui...

You don't have to use vim gui. You just install gvim, and you keep using vim. Except that vim will now have python and mouse support.
If it doesn't have mouse support, I would suggest checking your config. But this is completely off-topic.

I have checked my config twice. It was working well on older vim package. Now I don't have mouse support in cli. It worked, but after making gvim package by myself from abs. So now almost everything is fine. But so far I still think that clear vim package should have python support. Why perl, not python? [;

Why perl and not python was explain in short here and there are lengthy discussions in other bugs/feature requests about the merrits and the short comings. I'm with Xavier here, I think your config is somewhat busted or I didn't explainwhat you have to do clearly enough. I have gvim installed and when I type vim in urxvt(xterm the same) I have full mouse support etc.
The only one thing that comes to mind is, that we now with the vim packages do not touch the /etc(g)vimrc files anymore. The old package contained I think one or two mouse related entries people were complaining about that might trigger the behaviour you experience. Seems people don't like features so we remove them :(
The lines I'm talking about:
" In many terminal emulators the mouse works just fine, thus enable it.
if has('mouse')
set mouse=a
endif
see if your .vimrc has something like that and if not try it. HTH.

As I said, I had that 'mouse=a' in my vimrc. It wasn't working until I recompiled gvim package from abs. Then "It worked".

Also in way of compromises... what is the compromise in removing two very popular and very active developed programing languages support and left one witch developing process is in deep stagnation and witch is loosing much on popularity?

you are splitting semantics here I think,
- Python support is in the gvim package which provides a perfectly usable
vim binary, from console or terminal, and I don't see why it is asked
too much to install that package, when you are coding from terminals
anyway. Again, assuming you use the vim binary from that package, not
the gvim symlink.
- Yes Ruby got removed, but that's temporarily until vim supports Ruby's
1.9/2.0 interface out of the box

I'm using gvim right now, but the bug topic is vim package so I'm not splitting anything. I'm still don't understand why perl...

Applying the perl interpreter makes the application not really bigger and does not increase footprint, with the python interpreter it does(roughly doubles the size of the vim binary, and increases footprint). That has something to do with the linking is my guess. We had a bug requesting that all interpreters should become optdepends and that was what I would have preferred but vim does not work this way unfortunately so we hasd to settle for compromises of size and functionality.

I think that on this way good compromise is vi package, not vim. If I want to use editor with compromises that You've mentioned I'd choose vi package.

It was the plan to decouple the runtime from vi because that caused many other troubles.

Great. But why the losers on this compromises are vim python coders? From 'micro' vim, full vim and overweight gvim, we now have useless vim and overweight gvim. I really don't see the compromise. Why not vi, full (maybe temporary without ruby) vim and gvim? I think that this would be really good compromise for every 'conflict' (maybe it's not the best word for that) side.

Why? Because everyone who want to have lightweight editor would install vi. Another group will have real vim, there will be also gvim for GUI users.

Gvim is front-end, nothing more. Vim is core/basic! In this case is everything bad, unlogical, becouse we must install basic parts of vim from extra front-end.
This is so stupid, unbelievable.

If you have nothing helpful to contribute, please just keep quiet.
Just whining without any good arguments is completely worthless.
Besides, Arch philosophy is that when you are not happy, you do it yourself. If you use Arch without knowing this core principle, you are nuts.

If you want to be helpful, there are two things to figure out :
1) check if enabling python dependency almost doubles the executable size, and find out why
2) find out if there is really no way to make this dep optional

Xavier: Yeah, worthless. For vim as depends will be added gvim or gtk? :) Oh, please.. Seriously this is not good to put this in gvim. Better is separate vim-support-python package..

"If you have nothing helpful to contribute, please just keep quiet." @Xavier You've mentioned Your fictive compromises?
Following the Arch philosophy that isn't KISS philosophy anymore, this idea with a basic functions in 'extended' package isn't good.
It would be much better do full vim package as I said before or following @Krzysztof idea do vim-python-support package witch would replace old vim binary, same as gvim.

Ugh, there should be "same way as gvim", sorry.

sirmacik: not the same way. In vim-support-python will be only files to python part of vim. Like other "optional depends". This same way is on the other distros.

But as @Tobias said it can't work that way.

I did a bit more testing and there are a few more things to be said:
- firstly, no vim-python package, that would be against the ArchLinux KISS philosophy
to keep things simple and straight forward
- as mentioned by others and myself, interpreters are linked in at compile time or
forced loaded on startup with dlopen, that means they have to be installed on the
target system. Perl, Python, Ruby are included in different ways but when not being
installed on the target system the effect is the same that vim does NOT work
- the last time I compared a python enabled vs a python disabled binary was probably
more than a year ago. Seems things have changed and the binary is roughly the same.
However, the memory usage is significant 5.4MB vs 3.4MB when loading the same file
- The other big question that arises is the following: People are bitching about the
not so functional mouse in vim becuase it has no x-support. If we enable xsupport,
python and upon it's return also Ruby, what is gvim then? Just the same think with
GTK linking? We have to draw the line somewhere. And it does not make sense to have
2 esentially identical packages in the repos with a different name.

Python/ruby support is not the same as x-support... On one of my computers I can't have X installed. I can program without X but without python I can't. Whats then?
This bug report is about python support we're not talking about X, because removed X support is completely understandable for me. So the argument with X is for the other discussion. We know that for ruby we have to wait some time, from well known reasons. With python enabled binary size is not changing much (@Xavier You wanted to be helpful? [; ). I think that Your conclusions are opening us way to restart our discussion with fresh materials [;

And I don't see Archway as KISS philosophy anymore. So for me it's not good argument. Forgot to mention it again...

The reason why I brought X support into the picture is a bit different. Adding Xsupport apparently offers better mouse support for vim in terminals as well as it enable to run vim as a server that could be scripted by commands. Both things can be useful for people even if they do not request the gtk binding for gvim capabilities. What I'm saying is that as a package maintainer I do not have the privilege to consider every request separately and roll a package for each one because quite obviously that's not feasible. So talking about X, just because you did not request it is NOT the other discussion. And the KISS philosophy is not for sale, certainly not for me.
Picture the following, we have a user that really wants x support for the mouse but does not need python. The standard vim package is not sufficient for him either. I'm saying if you are serious about developing with vim then install the "BIG" package. Also if you want netbeans support, you need the server capabilities and the big package. Same for Python scripts.

Great, in most cases I'm not using X for python scripts... And I was using vim also because it's not as netbeans - now it is. And I'm serious with that that only one of my computers has too small disk space to install there whole X with gtk. So for me it's not a solution at all.

you don't get the point. I mean vim is not Netbeans it never was and never will be. The feature enables vim to be used from within the netbeans IDE, but also enables other plugins to work, such as vim eclipse or even just clewn(a gdb interface for vim handy for C coding). I brought it up because it was another feature request and it went straight to gvim.

But it don't change anything in the following sentence: "So for me it's not a solution at all". With the reasons I've listed before.

sirmacik:

abs

cp /var/abs/extra/vim .

cd vim

vim PKGBUILD

makepkg -if

Waw, lol... thanks that's the way I'm working with vim now -.-

I think the current system works well enough. If you want Python, Ruby, Tcl, etc. support it's easy enough to use ABS and add it yourself. It doesn't make sense to include support for packages that aren't in the base system in vim. It doesn't make sense to have a million vim packages (vim-python, vim-ruby, vim-tcl, vim-python-tcl, vim-ruby-python-tcl-perl, etc.). And it would be impossible to have this kind of support in auxiliary packages since the difference is in the vim binary.

Agreed with Chen on this one.