On 13/01/14 01:56, tooth pik wrote:
On Sun, Jan 12, 2014 at 09:20:02PM +0900, Andre Sihera wrote:
On 12/01/14 18:50, Thiago Padilha wrote:
Having support for multiple scripting languages would certainly be useful.
One simple way to achieve this would be to follow weechat's take on
plugins(http://weechat.org/files/doc/stable/weechat_user.en.html#plugins)
where each plugin is a dynamic library loaded at startup(eg: dlopen)
by vim's core program. This would enable vim to support any language,
as adding support to a new language wouldn't require recompiling vim,
just add a file to the runtime dir.
Each dynamic library can embed its own interpreter and handle
converting to/from vim's data structures, and it should also have a
initialization function that would be called by vim at startup time.
This function could be used for example, to register a vimscript/ex
commands for calling the language interpreter(eg: python<<)
In any case, this would imply in significant changes in the current
way vim works, so good luck getting such a patch to merge in the main
code.
The DLL-style plug-in implementation is how I was imagining
it.
Although changes are significant, they could be reduced if we
implement the default language binding *on top* of the current
command implementation as opposed to rewriting the current
command implementation on top of a new language binding
feature ("smoke and mirrors"...)
all so we could add interpreters without rebuilding vim? Sounds like a
lot of code, a very lot of added complexity and bloat to achieve
something we can already do with a simple rebuild. This particular
voice from the peanut gallery will be voting against it if it ever makes
it that far.
In view of the fact that vim is first and foremost a programmer's
editor, I think the requirement to rebuild so you can use something
other than vimL is akin to telling humans they have to breathe if they
want to continue living.
This proposal with its external DLLs would would hardly affect
the size of the core binary due to most extra code being in the
DLLs, so your worries about "code bloat" may not apply here.
Humans don't have to be told to breathe in order to continue
living. Of course not! And in the same way, programmers
*should not* have to build their own tools just because they
can. You think all hairdressers want to cut their own hair? Or
that all tailors want to make all their own clothes? Ridiculous.
Programmers operating in highly competitive IT sectors where
speed and efficiency are King and are necessary just to be able
to survive. The editor is the programmer's most fundamental
tool and he/she should be able to exploit current *and future*
interpreters instantly, without recompilation; like "breathing air".
For people like yourself who want to recompile ViM every time
you want to add or remove a feature, there is the "tiny" build.
And while you're constantly recompiling, other programmers
who run with the "huge" build of ViM by default, and have all
the features and interpreters automatically at their fingertips,
will be more productive, will be finishing their work quicker,
and will be commanding bigger pay rises from their bosses.
I would be interested to know: how many other programmers
prefer to run the "huge" ViM build purely due to the ease and
improved productivity with not having to constantly recompile?
--
--
You received this message from the "vim_dev" 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_dev" 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/groups/opt_out.
