On Nov 25, 2013 5:24 PM, "Marc Weber" <marco-oweber@gmx.de> wrote:
>
> I've been complaining about Vim related issues for a long time,
> I think its time to stop complaining and just fix it.
>
> Join by providing feedback:
> http://mawercer.de/vim.php
>
> or adding additional issues to be fixed here:
> http://vim-wiki.mawercer.de/wiki/topic/in-which-way-does-vim-suck.html
>
> The idea is to create a kickstarter project to funding all work.
> IMHO Vim is worth keeping alive, and that means we must find a way
> to move Vim into the future.
>
> If this requires writing a new language, because C lacks abstracktions,
> and C++ is complex, then that's the task to be done IMHO.
>
> This project makes me think we might have success:
> http://www.kickstarter.com/projects/maxcantor/beautiful-vim-cheat-sheet-poster?ref=live
>
> Thus if you're either a developper or a user who wants to help join and
> tell me what you want to work on - even if its "testing new features you
> care about" only.
>
> Goals are:
> - focus on productivity
> - code reusage
>
> I consider refactoring viml a key thing, eg creating a viml library
> which contains the interpreter only.
>
> If you'll help me with this I'll be working on Vim related topics the
> following month, otherwise I'll get any alternative job.
>
> I feel I've hit a border meaning some core items must be fixed in order
> to improve even further, and most people cannot afford dropping out of
> job and work 8 weeks on Vim.
>
> The work will be
> - defining goals
> - fixing them
>
> This work might end
> - in rewriting huge parts
This has to be expanded. No doubt it needs to be done, but this statement is too broad.
> - introducing threading (python, ruby ctrl-c does not work)
Ctrl-C is not as much an issue as thread unsafety when it comes to threads.
I guess you will have to start with removing globals scattered over all files. This part can be iterative (a few globals per patch assuming we are not forking and have permission from Bram) and is relatively simple at start.
I was thinking about starting a new series of patches with sole purpose of removing globals, but without a) experience in C multithreading (i.e. knowledge of what ultimate goal requires me to do) and b) permission from Bram or some will to do a job of convincing him (with a) badly hitting my positions) I cannot start it.
> - have your whatever beloved interpreter as standard interpreter
No much sense. VimL is better with its :s/:g/:... commands for quickly writing something simple for text processing. Having command like :pyrepl to run python REPL (and same for other interpreters) would be handy to quickly writing something relatively complex though.
Making some interpreter standard not only risks slowing user down, but also makes it close to impossible to use other people's vim.
> - add js support (v8)
This has to be a low priority, especially considering v8: Gentoo maintainers have masked it for removal as it "does not have stable API resulting in compile breakages in reverse dependencies". There is no way you can refactor vim and fight with this at the same time, and I guess not only Gentoo maintainers will not be willing to deal with it.
Especially considering that there are no plugins written in javascript for an obvious reason and javascript is not the best language you can pick for embedding.
> - compare with Yzis
> - think about whether gobjectIntrospection interface can be used to
> share work on interfacing with interpreters in the future.
> - maybe introducing a new higher level language which is friendly to C
> and less complex than C++ - yes, sry - I consider C to be a problem
> because its hard to share code, eg reuse the syntax highlighting from
> within JS and so on.
I would consider D in first place. Not that I actually worked with it, but I have read lots of articles convincing me that it is way better then C++.
There are other concerns though: C is portable (with lots of macros, but they are primary isolated), there is a way to use a C function from nearly anywhere (e.g. like with python ctypes, etc), there is a big bunch of things that have C bindings and sometimes are even written in C and it does not forbid any optimization you may come up with.
I do not understand the statement about reusing syntax highlighting though: you either write in JS, something that compiles to it (C *does*) or forget about the idea AFAIK (assuming you are talking about browser js).
I would suggest limiting options to only languages that work on all kernel+architecture combinations debian works.
> - ..
>
> Of course if you think "vim is great the way it is" (I agree)
> and if you think "nothing should be changed" I tend to disagree.
>
> If you don't receive much feedback I'll try the kickstarter project
> adding features I think are most useful to start with.
>
> 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