On Dec 2, 2013 5:25 PM, "Marc Weber" <marco-oweber@gmx.de> 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 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