On Sun, Jan 12, 2014 at 11:00 PM, Andre Sihera <[email protected]> wrote: > > > 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?
I have been wondering if it is feasible, or has been discussed, to provide a C API that exposes Vim's functions and state, to provide a "Vim core" (sort of like libgit2 provides git functionality without having to wrap shell commands). Even without non-C language bindings, a C API that allowed an IDE or some other editor to "host" the Vim core could enable modern Vim implementations without having to actually reimplement Vim. I think that is a much better idea than re-writing Vim in C++, which has been discussed on vim_dev and vim_use. Justin M. Keyes -- -- 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.
