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. On Sun, Jan 12, 2014 at 4:48 AM, Andre Sihera <[email protected]> wrote: > Dear all, > > Apologies for this long-ish post. Your patience is appreciated! > > The Original Poster who suggested "every primitive vim operation > should have a descriptive name" was thinking exactly the way that > ViM should be positioning itself in order to be able to support > any language binding that we want to in the future. The Original > Poster was, unfortunately, thinking way ahead of his time given > ViM's current "construction". > > I have been considering proposing a ".Net-style" language-binding > upgrade for ViM for some time now and I would now like to take > this opportunity to share my particular take on the idea and to > get everybody's opinions. > > Currently, as well as the main operation modes that ViM has > (insert, normal, command, etc.), there is also ViM script which > has a huge number of very useful and flexible functions to drive > every feature of ViM (from now on, called "Primitives"). > > The idea I have is to create an internal default language binding > called (for example) "VIM", and to hang all the current commands > off the internal binding. The following is NOT a literal > specification for such a binding, but it could look something like > this: > > VIM > | > +--- Insert > | | > | +--- (all insert mode commands) > | > +--- Normal > | | > | +--- (all normal mode commands) > | > +--- Command > | | > | +--- (all command mode commands) > | > +--- Script > | > +--- (all script functions) > > Once this default binding is in place, we then create "aliases" > onto the primitives for all the existing commands and script > functions so that the Ex command language works exactly as it > does now (guaranteeing backward compatibility and continued > POSIX compliance). > > For example: > > stridx => VIM.Script.stridx > > Once this is done, it could then be easier to support any other > language binding by creating a new language binding module. E.g. > for python interface, we could take "python-style" object > references and convert them to and from the default language > binding using some kind of "interface description language" > that knows about fundamental data types, data widths, calling > conventions etc. > > This is the reason I originally referred to this proposal as a > ".net-style" upgrade. So, for example, in python: > > vim.str.find => [INTERFACE DESCRIPTION] => VIM.Script.stridx > vim.str.index => [INTERFACE DESCRIPTION] => VIM.Script.stridx > > (see: http://docs.python.org/2/library/stdtypes.html#string-methods) > > The huge advantage with this method is that while ViM is not object- > oriented in its implementation, it would still be able to support > object-oriented language bindings thus no fundamental rewrite of > ViM in an "object oriented language" would be required. If a pure > object model in the target language is required it can be > implemented in the target language with a final call to the ViM > language binding. > > At the same time, it would also stop the childish "script language > X is better than ViM script so why don't we dump ViM script and > replace it with X?" arguments that pop up all too frequently on > this mailing list. > > Finally, the Original Poster's suggestion "every vim primitive > operation should have a callable descriptive name" could also be > supported. Instead of using the Ex command "alias" for the command > "normal vippp", the OP could use the default language binding > directly and call (for example): > > VIM.Normal.Visual(); > VIM.Normal.Insert(); > VIM.Normal.Paste(); > VIM.Normal.Paste(); > > etc. > > > Forget about the implementation details at this stage. What about > the concept itself? > > > Thanks in advance, > > Andre Sihera. > > > > On 12/01/14 13:36, Mosh wrote: >> >> All builtin vim operations should be named for 2 reasons: >> >> 1. if you map a key, then the original command binding is unavailable: >> example: :map [ 0 .. >> Now how do I call [c in diff mode; [c doesn't have a name. >> >> 2. scripts become un-maintainable and unreadable to others: >> simple example. ".....exe normal vip ......" >> :h vip >> Vim help doesn't know what vip is is, >> only google can help you here. >> >> This is just an example, but many operations cannot be found in vim >> help >> unless you already know about it. That is why vim-tips is such a >> useful site, >> and emacs-tips site is unnecessary - because every command is named >> and >> can be grepped for. >> >> thanks, >> mohsin. > > > -- > -- > 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. -- -- 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.
