On Dec 2, 2013 10:41 PM, "Marc Weber" <marco-oweber@gmx.de> 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 vim_use+unsubscribe@googlegroups.com.
> 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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
No comments:
Post a Comment