On Dec 2, 2013 5:25 PM, "Marc Weber" <[email protected]> wrote:
>
> Hi Nikolay
>
> I've turned your suggestion into a page about order of steps to fix Vim:
>
http://vim-wiki.mawercer.de/wiki/vim-development/fixing-vim-next-steps.html
>
> Have a look at the (Comment ..) text, please add some samples. Code can
> be added by
> {{{
> ...
> }}}
> I've also added you as collaborator to
https://github.com/MarcWeber/vim-git-wiki.
> See http://vim-wiki.mawercer.de/wiki/this-wiki/contributing.html
>
> Duplicating my comments here so that items can be discussed.
> (If you reply here I'll just update the comments)
>
> Excerpts from Nikolay Pavlov's message of Mon Dec 02 08:41:43 +0100 2013:
> > - Making vim embeddable (making it second point since it is even more
> > refactoring).
> Keep in mind that Yzis team failed on this, see
> http://www.freehackers.org/VimIntegration (which was posted in this
> thread earlier)
>
> > - Stripping requirement to use VimL in Python/Ruby/Lua/etc interface.
I.e.
> > finishing what I started (I guess I can do this) for python and doing
the
> > similar thing for other languages.
> I don't get you, can you elaborate?
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.
> > - 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.
There is a big bunch of Unicode properties that you can place inside figure
braces there and they are there for a reason. The most severe are more
general groups: e.g. what is the regex for matching variable name in python
3 (ignore reserved words for simplicity)? Hint: it is not \<\a\w*\>: Python
3 supports using non-ASCII in variable names.
>
> > - Possibly sane unicode indexing (may require further string
refactoring to
> > be efficient).
> Use case ?
You are at the column N and want to get character before the cursor to
decide the behavior of Tab. Assuming you are writing text in LaTeX in
Russian and want to detect whether it is Russian letter just before the
cursor to do something special. The best idea would be using indexing, but
it is wrong, so you have to use matchstr().
matchstr(getline('.')[:col('.')-2], '.$') vs getline('.')[col('.')-2].
This can be worked around, but workarounds are ugly. And there is big bunch
of plugin developers who do not care about unicode and thus do not have
such workarounds (consider the relatively recent issue where one Russian
man wanted to use IMAP() to map some Russian letters and was unable to for
this very reason). Good language is not about "care about things or they
will not work". It is about "you see how many things work without you
actually caring about them".
I have yet to see a language which is not going to bother me with encoding
issues.
>
> > - Non-string funcrefs (i.e. inclusion of my patch (without lambda
part)).
> > It contains fixes for some problems.
> Again, just add a section to
http://vim-wiki.mawercer.de/wiki/topic/in-which-way-does-vim-suck.html
>
> > - Stripping requirement to use shell to run applications.
> Again, a use case would help much understanding what you mean exactly.
system("frobnicate ".shellescape(@%)) vs system(['frobnicate', @%]). It is
again very easy and common to forget about escaping or do it wrong. But it
is even easier to have your plugin screwed up just because vim has no way
other then passing argument to cmd.exe with clumsy escaping. Check python
subprocess module to see how to do it right.
---
Also using pipes and not temporary files is faster and sometimes more
reliable. It has to be a separate issue I have not mentioned.
>
> 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.
