On Dec 2, 2013 9:25 AM, "Marc Weber" <marco-owe...@gmx.de> wrote:
>
> Excerpts from Ed Kostas's message of Sun Dec 01 16:01:42 +0100 2013:
> > I want to join, but I receive the following message when I try:
> > You don't have permission to access /x/php.fcgi/index.php on this
server.
> Your message to the mailinglist has been enough, I took notes.
>
> The pages will be back soon, I've problem with php-fpm access rights for
> some wired reasons after trying an update.
>
> > > http://vim-wiki.mawercer.de/wiki/topic/in-which-way-does-vim-suck.html
> > I receive the above message when I try to access this link too.
>
> You can read the source @ github, too:
>
https://github.com/MarcWeber/vim-git-wiki/blob/master/vim-online-wiki-source/topic/in-which-way-does-vim-suck
>
> I think the first important thing is to collect things to fix, then
> workout how to fix [1] them, then estimate costs and try to get funding.
I think that the most problematic thing to fix is threading. You cannot add
thread safety without a very huge rework that starts with removing global
state (unless we are going to say that GIL is good enough). And it will be
problematic to add other changes while refactoring is in progress.
>From my point of view this list should look like this:
- Threading.
- Making vim embeddable (making it second point since it is even more
refactoring).
- Input (I mean this constantly popping out discussion with vim not
supporting certain keys).
- More input (iminsert and keymaps are not good at all at handling people
using 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.
- Zero byte handling. Low priority since this is uncommon to have in text
files, 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).
- Unicode support in regular expressions.
- Possibly sane unicode indexing (may require further string refactoring to
be efficient).
- Non-string funcrefs (i.e. inclusion of my patch (without lambda part)).
It contains fixes for some problems.
- Stripping requirement to use shell to run applications.
> Thanks for your interest.
>
> Marc Weber
>
> [1]: And I don't know this yet. This will take some time.
>
> --
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
