unfinished work - how to fix Vim - which order - next steps?

Important fork neovim.

older items:

• Which platforms to support?Windows terminal, Windows GUI, unix like terminal, Operating System / Targets: Unix like (tty, X11, Qt, Gtk, Wayland, ..), Windows (GUI, terminal), OSX (Aqua?), ..

• Threading.

• Making vim embeddable (making it second point since it is even morerefactoring). (Comment, Yzis failed on this, see http://www.freehackers.org/VimIntegration)
• Input (I mean this constantly popping out discussion with vim notsupporting certain keys).
• Zero byte handling. Low priority since this is uncommon to have in textfiles, but in the current state you have to write ugly hacks to make it work. Should probably be the third as it implies refactoring string implementation. Possible solutions I see: escaping like in zsh (note that it is done the way you never notice) or struct {size_t len; char str[1];} (where you allocate string using usual alloc(sizeof(str_T) + len) hack).
• More input (iminsert and keymaps are not good at all at handling peopleusing more then one keyboard layout: gvim needs a way to get actual keys pressed and process them as if they were user English layout (not hardcoded us keymap) regardless of actual layout when not in insert or command(?) modes).
• 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. 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. => gobjectIntrospection, is this of any help?

• Unicode support in regular expressions.Eg how do you match a Russian word? This will be /\b\p{Cyrillic}+\b/ in Perl. What about allowing to use PCRE

• Possibly sane unicode indexing (may require further string refactoring tobe efficient). (Comment: Nikolay, please explain, add a simple 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.
maybe JS, string characters are unicode only ..

• Non-string funcrefs (i.e. inclusion of my patch (without lambda part)).It contains fixes for some problems. (Comment: Nikolay, please explain, add a simple use case, also consider adding this to recent-work) if you already have a patch

• Stripping requirement to use shell to run applications.(Comment: Nikolay, please explain, add a simple use case)

• Think about which guis to maintain well and which to maintain less

• What should happen on ctrl-c? Tell user what Vim is waiting for, thensecond ctrl-c hit aborts?

Can be done with current Vim by patching runtime or the like (not much work)

• VAM's shell DSL
• vim-addon-error-formats
• Threading. This patch implements a solution based on a simple message queue/event loop that can be integrated into the current code without much effort(need confirmation by a developer with more experience in vim's code)

Problems to be fixed see in-which-way-does-vim-suck

random ideas

• evaluate libuv (because it abstracts many system tasks) according to Thiago Padilha.

• evaluate this library with many backends ?http://git.enlightenment.org/core/efl.git/tree/src/modules/evas/engines