On Dec 2, 2013 8:44 PM, "Marc Weber" <marco-oweber@gmx.de> wrote:
>
> Excerpts from Nikolay Pavlov's message of Mon Dec 02 15:56:25 +0100 2013:
> > Currently such interfaces are pretty much useless without using vim.eval or
> > vim.command (or equivalents in your language of choice). I started creating
> > wrappers around various C structures (like that vim.options thingie
> > wrapping functions that manipulate options array) that strip out
> > requirement for vim.eval/vim.command.
> => TODO: would gobjectIntrospection system help? AFAIK it can generate
> beindings to gobject like interfaces automatically for most scripting
> languages
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.
>
> > > > - Unicode support in regular expressions.
> > > Can you also provide a simple use case, here ?
> > How do you match a Russian word? This will be /\b\p{Cyrillic}+\b/ in Perl.
> So what you're aksing for is [a-zA-Z] but include language specific
> characters such as ß in German or whatever is used in Russia?
> Something smarter than [^ \t.;:!"'] (trying to match non word chars ..
> but that's not going to work well)
It is locale and not unicode support, though they intersect. I understand that locale support will break plugins, thus I asked only about unicode. This is not about ranges, but about character properties.
>
> > PCRE:
> In fact that was what I proposed to Bram, I even wrote to the PCRE
> mailinglist to understand how to use it (feed data in incrementally).
> Bram disliked the idea ..
> I'm in favour of "reusing code" if possible. I'm not in favour of
> maintaining everything myself.
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.
>
> Also they were refactoring the interface.
>
> Well "just improve" is not enough. We have one use case {Cyrillic}, but
> which additional ones to support?
All unicode properties. I guess you may use icu to fetch characters with a given property into a collection. Maybe existing API allows faster variants.
It is useful for things like stripping diacritics or finding variable names. There are more uses I cannot imagine thus there is no need for restricting support to just some unicode properties unless there is some technical reason for it.
>
> > > > - Non-string funcrefs (i.e. inclusion of my patch (without lambda
> > part)).
> Oh by the way: I introduced kind of, see vim-addon-mw-utils
> funcref#Function or such. It allows storing a function to be called and
> some args to be passed first. It also allows to evaluate strings.
>
> Its not perfect, but quite useful.
It is not this. Problems solved include:
- Possible deletion of function that is referenced somewhere.
- Weird anonymous function names.
- Restriction for deleting functions being profiled.
- Using python callables as vim functions.
This list does *not* include partial application, not without lambda subbranch.
>
> > system("frobnicate ".shellescape(@%)) vs system(['frobnicate', @%])
> Have a look at VAM's shell dsl. it comes very close.
I know it. It is not close, not a tiny bit. Main problem is not escaping, it is shell itself. There is no way you can use system()/:! and not use shell.
>
> > again very easy and common to forget about escaping or do it wrong
> I agree. Also system vs :! requires different quoting etc.
>
> > Also using pipes and not temporary files is faster and sometimes more
> > reliable.
> r! ...
> :cbuffer
> :-)
It is too smart about line endings.
> Added this to the sucks page
>
> 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