On Dec 2, 2013 11:35 PM, "Nikolay Pavlov" <[email protected]> wrote:
>
>
> On Dec 2, 2013 10:41 PM, "Marc Weber" <[email protected]> wrote:
> >
> > Excerpts from Nikolay Pavlov's message of Mon Dec 02 18:12:00 +0100
2013:
> > > Wondering whether gobject may make python-vim API look like rather
regular
> > > python module and not like something ctypes-based with many
implementation
> > > details leaking.
> > Writing a small python layer on top should be easy.
> >
> > > I do not remember clearly, but was not it suggested to take PCRE
syntax? I
> > > do not remember any discussions suggesting taking PCRE and replacing
parser
> > > code, but I may have missed something.
> > I don't remember wether it was public. Facts: PCRE is fast, it already
> > implements what Bram had in mind, it even has JIT support.
> > But yes, it would be PCRE syntax, too. (Is this good or bad?).
>
> It is bad. Everybody is using vim syntax and thus PCRE one is not
acceptable for it throwing away backwards compatibility with exactly no
nice ways to work around.
>
> >
> > > All unicode properties.
> > Add references to documentation what you have in mind (wiki).
>
> Unicode property is an already defined entity. Maybe need a link (though
do not know where to as perldoc perlre and some icu examples assume you
know what exactly "unicode property" is).
>
> >
> > > It is not this. Problems solved include:
> > > - Possible deletion of function that is referenced somewhere.
> > What for? Don't understand what you mean.
>
> You can define a function, reference it and do :delfunction. Now
reference is unusable. My branch holds a reference to function definition
in funcref variable so that as far as you hold the reference you are
guaranteed to run exactly the same function you referenced.
>
> Note: this means that if there is reference somewhere when you redefine
function that reference will still use old definition. I consider such
stability an advantage.
>
> >
> > > - Weird anonymous function names.
> > Talking about dictionaries? :function{23} will provide more information
>
> Which is very inconvenient. And it does not provide a name. I am losing
the ability to use :fu without holding a reference in that branch, but it
is possible to have :fu working with the error output and have normal
function names at one time with a more or less minor patch, but I like
current state much more since it a) is less damaging to debugging then
numeric names are (too easy to workaround and trying to use :fu in the only
case I actually *may* have preferred it over browsing source code (long
generated functions) is very inconvenient without syntax highlighting (do
not recommend :redir to a file and then opening it: it is far less
convenient then what I have)) and b) makes anonymous functions not global.
>
> >
> > > - Restriction for deleting functions being profiled.
> > > - Using python callables as vim functions.
> > You can do this all - kind of.:
> >
> > You can define helper function
> >
> > fun! CallPyAndReturn(py-expr)
> >   py a = a:py-expr
> >   py return a
> > endf
> >
> > Then
> >
> > let my_funcref = funcref#Function('return
CallPyAndReturn('python-thing', ARGS[0], ARGS[1])', [2])
> > # my_funcref contains first arg. Second arg still has to be passed:
> > let x= funcref#Call(my_funcref, [arg_2])
>
> Make this a) automatic b) automatic and fast and c) make it friends with
GC so that you cannot dispose python object when you hold a reference and
you will dispose it when you don't.
>
> And your code is not going to work. There are way too many mistakes for
such small piece of code. I do not even get an idea, so I am pretending the
idea behind this code is the same as I would have written: store python
callable into a dictionary, generate an anonymous function which calls it
with "*vim.bindeval('a:000')" as arguments (am not sure whether star
accepts any iterable and not just tuple and list, so this may as well be
"*tuple(vim.bindeval('a:000'))") and return the result of the call. Like
this:
>
> py << EOF
> callables = dict()
> def store_callable(c):
>   key = id(c)
>   callables[key] = c
>   return c
> EOF
> fun GenPyCallable(expr)
>   let id=pyeval('store_callable('.expr.')')
>   let d={}
>   exe "fu d.f(...)\nreturn
pyeval('callables[".id."](*vim.bindeval(\"a:000\"))\nendfu"
>   return d.f
> endfun
>
> . I am not sure whether I have everything here right (especially
escaping), but this is exactly why I first express the idea in English.
>
> Note that there is also no way I know that allows to do this and keep
context (i.e. l: and a: locals or absence of them for use with vim.*eval).
This is poind d).

There actually is a way to keep context: make it a *python* function and
not vimL. This makes it harder to use though and if you cope with a) (which
is not very hard) you still will not be able to construct a drop-in pyeval
replacement for this reason. I.e. GenPyCallable('foo') transforms into
pyeval('gen_py_callable(foo)') (note: foo is not a string argument here:
using eval in different context omitted).

>
> >
> > > This list does *not* include partial application, not without lambda
> > > subbranch.
> > Please document your work on the wiki. We need to have a primary place
> > to share ideas/ work/ ..
> >
> > Marc Weber
> >
> > --
> > --
> > You received this message from the "vim_use" 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_use" 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_use" 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_use" 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.

Reply via email to