On Dec 2, 2013 8:44 PM, "Marc Weber" <[email protected]> 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 [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.