Alexander Shukaev wrote:
I'm afraid you overextended the topic. Now, let's try to filter what
you've presented with a cool head.
I've never said Perl is bad or anything like that.
----
I don't think I claimed you said that -- you said it wasn't trendy. I
Every language has its own niche. The point was that many modern and
very popular plugins these days are not written in Perl. That's what I
meant by "trendy". Did you look through those 270 hits? Who uses those
plugins? Or are they simply outdated legacy? I have tens of thousands
of downloads of this Vim distribution.
----
Since perl and cpan is distributed via a network of 100's of mirrors
-- there is no easy way to keep a central accounting. It wasn't
practical to keep it in one place where one could count the number of
downloads because the bandwidth costs when perl was developed, were
prohibitive. That hasn't changed that much. I have used some of those
scripts so I know they aren't outdated legacy, but vim was too slow
parsing all of the vim-script related to using those plugins, so I
stopped using it. The problem is that vim parses all of the setups of
those scripts each
time it starts, whether those things are used or not. Most of the time
I'm not using
a perl debugger, so it wasn't practical the way the vim scripts were
setup.
...and every user is free to create an issue to request something. I
was requested Lua, for example.
You were also requested perl -- BUT...
But nobody ever complained about the lack of Perl, and most likely
because nobody cares about it, as nobody uses any plugins relying on
it or does command-line scripting with it.
There are plenty of debugger integrations for Vim out there, and
therefore reasoning that IDE request is #2, and that just one of its
aspects, debugger facility, was written in Perl is quite weak
argument, and the connection is rather indirect.
It's not a debugger facility -- it's an IDE. keyword completion,
refactoring code,
reformatting, but there are better perl IDE's out there, so it probably
isn't used as much
anymore.
And no, I didn't link against shared libraries because that makes no
sense.
----
This makes the discussion mostly moot. I wasn't arguing or wanting a
vim w/all of them linked in, but the version that looks for all of them
dynamically
they way it has historically done.
I'm used to the vim's that were built with run-time dynamic loading
of available
libraries. It doesn't cost anything to include the hooks for loading --
but if you are
linking all of them in... *ouch*. It used to be the case that the
Windows version was
the best example of using DLL's -- because if you wanted one of the
languages,
you provided a standard DLL, and vim would load it the first time you
tried to use
the language. If you never used it, it never looked for it.
The cost for adding each language is about 1.5M... The version with
all the languages
bound in is about 8.1M. The version with them dynamically loaded is 2.1M.
If you are creating a version with them all linked in, then I can't
justify including
perl as I wouldn't use such a version. I thought you were using the
version w/hooks
for each of the languages. They *run* the same except the dynamic one loads
considerably faster and only loads the languages you actually use the
first time it is
used.
Sorry for my misunderstanding.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
