ZyX wrote:
> > We also need to keep in mind that all the Vim functionality is nicely
> > documented and there are examples, while if we add a different way to do
> > this in Python this requires documenting how that works. Thus a script
> > writer will have two sets of functionality to learn to use. It will be
> > good to have "how it's done in Vim" to be very similar to "how it's done
> > in Python". Otherwise it gets very complicated.
>
> Nope. It is now when script writer has to know “how it is done in
> Vim” in addition to knowing vim<-->python interface. Target of the
> new interfaces is that plugin writer has to know only if_pyth.txt for
> all things he may need to do. RFC is here to discuss how implementing
> my proposal completes this target and what other things need to be
> included.
That is impossible. You may skip some of the list, dict and other Vim
language features, but when it comes to options, regexp, autocommands
and many, many other things you need to know how Vim works. Making a
Python interface for them won't change how Vim works.
For example, you can make some easy way in Python to set the 'tabstop'
option. To know what the effect is you still need to know about the Vim
option. Now, since that is a number option it's easy, but when you get
to the more complicated options you are just doing string manipulation.
Also keep in mind that the user will still have to type most Vim
commands. E.g., making a Python way to set an option that is a list of
names using a Python list might be nice, but the user still sees the
result as a string and has to type the string when he wants to change it
manually. Thus you won't be able to just omit this part of Vim
commands.
We really need to concentrate on the basic, generic mechanisms. Not try
to make a Python equivalent for every single Vim item. I mean, we don't
want to replicate every Ex command in Python, right? But we could add a
Python command that makes it easier to execute Ex commands, e.g. by
passing the arguments as a list instead of as a string, and indicate
whether special chars need to be escaped.
> And adding python interface that is the same as VimL is
> 1. throwing away some of the benefits python provides
> 2. intentionally creating interfaces with design flaws
> 3. intentionally ignoring python principles like “explicit is
> better then implicit” (for 2. and 3. refer to my explanation of why
> *.options are written the way they are written).
>
> Not saying that I can’t imagine how to write VimL in python.
>
> > For the "expr" options this would currently be done by using pyeval(),
> > right?
>
> For *expr options, and map-<expr> this will be done using pyeval()
> even after the patch; for :command it is now and will after be done
> using :python. What the patch will add is
>
> a) Standard interface.
> b) No need in knowing and using VimL. Exact implementation will be hidden.
> c) When core vim features will allow this, implementation will change.
>
> About c): I still have not forgot about suggestion I have written
> earlier about function references: making them more generic by
> embedding struct func_S pointer in place of char* with function name.
> There are two additions since then: no s: in function references,
> reference counting for all (not only anonymous) functions (implies
> holding normal user functions in a regular dict_T like g: one, but
> hidden(?)), reference counting in struct func_S and normal names for
> anonymous functions (they will not be added to dict_T as with
> reference count and all other data in a structure attached to
> typval_T* unique names and holding anonymous functions with other user
> functions are no longer needed).
That's only indireclty related to the Python interface. Funcion
references are a bit of a hack.
--
GUARD #2: It could be carried by an African swallow!
GUARD #1: Oh, yeah, an African swallow maybe, but not a European swallow,
that's my point.
GUARD #2: Oh, yeah, I agree with that...
The Quest for the Holy Grail (Monty Python)
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
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.
