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"...)
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.
