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