On Dec 2, 2013 11:35 PM, "Nikolay Pavlov" <zyx.vim@gmail.com> wrote:
>
>
> 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).
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 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