In first, this thread is not about "Rewrite Vim by my like language".
>Your choice / my choice. I love Vim to. But I also think about all the >people which are to be born which have to learn viml just to get a >simple thing done in Vim - and you cannot reuse viml knowledge in any >way. That's why its nice to know, but its far from perfect. Yes, this knowledge may be not used in others. But it is only editor configuration! For example, Emacs' configuration knowledge can be used in other editors? It is not. >I know that forking Vim will divide community. But it will also make it >possible to other people to join again. I'd like to delay this >discussion till I know what I want exactly and whether I have time to do >it - till then having a place to summarize wishes is the best thing to >do. If you want to fork or rewrite it by other language, I don't stop you. But it is hardest way. >If granted you access to vam-kr. Do whatever you think is right. >vam_known_repositories#Pool() is the function returning all the magic. >Before talking about renaming you should tell us whether you think the >returned list of items is reusable to you. I can use this function. But to use it, I must reduce the code. I think independence from vam-kr functions is best. >If you think about big changes consider using a branch or creating a bug >report so that we can discuss your requirements. Requirements... I think it should be more simple. >- compile time hackery like meta programming. Eg have a look at haxes or > Scalas macro feature which allows generate ast at compile time. > Haskell template haskell system is similar. I think C++ is difficult language. There are few people who can write it right. And there are people who don't like C++. >>- also allow pure functional style (maybe lazy like Haskell, maybe not) >- maybe some record typing (like impredicative.com/ur?) >- using different memory management systems >- type classes (like Haskell etc) stuff like that. Can you write the editor by functional language seriously? Editor countains much IO and side effects. It is weak region in functional language. And It is too few that the programmers can write programs by functional language instead of C/C++/Java. So I think it is impossible. >No, because Zimbu is yet another language which will only be used by >Vim. I want to think more about this choice before starting to rewrite an >editor - after all Vim does work in its current state. I think it is not for time. We should think about it when Mr.Bram starts rewrite Vim. >> [..] or community will divide eventually. >Community already does - I mean people are switching to Emacs. Yes. It is free that people switch to Emacs. Instead of it, threre are people switch from Emacs(I know them). We should calm down. >Please stop thinking that "just starting to rewrite an editor" will >solve all issues. You need kind of design, and that does not exist yet. Yes. It is hard way. This is not thread for it. The agreement of Mr.Bram is necessary. >So, there are a lot of package managers already, for various systems. >I'm wondering if we should leverage what's been done there already, >maybe not to reuse the clients, but to reuse the way the repositories >were defined. Because, the repository data is important than clients. Are you want to spoil the data? >A good example would be FreeBSD's ports, for which there exist several >"clients" like portupgrade, porteasy, etc. This system has proved >usable and used for long enough to be worth studying. >Yes, and gentoo portage, ruby's gems (which is actually used by >https://www.relishapp.com/kana/vim-flavor/docs/philosophy >etc. >http://vim-wiki.mawercer.de/wiki/topic/vim%20plugin%20managment.html >talks about it (I've given this link multiple times). >and PIP has been proposed (python package management). >And let's not forgett about npackd. Yes. I want to study other package repository's features. >Look: VAM already has everything you need. You can even download plugins >for Windowns with dependencies: >http://vam.mawercer.de/ >I care about ending the duplication of work for the "didn't know about >it" reason. >Sorry I didn't look at the links. >My point was not that VAM or NeoBundle or anything else was better and >should take over, but more that maybe we should rethink the way >plugins are defined. Maybe it's high times plugins actually declare >dependencies, where to be downloaded from, etc, so as to make it >easier for any software manager to handle them. >I see that as a way to have a consistent distribution of plugins >whether you like to download them with VAM, or with apt-get, because >there would be a unified and well though format and repository for >storing them (or their meta data). Yes. I don't want to discuss about "VAM vs other plugin managers". I want to discuss about "(standard) plugin repository" than "plugin managers" or "rewrite Vim battle". Can you discuss about it, Mr.Marc? ---------------------------------------------------------------------------------------- "Practical neocomplete..." "Practical vimshell..." "Practical Dark Vim Master..." "Wait, You are ...!" "Fufufufu..., I AM The Dark Vim Master(暗黒美夢王/Uncock Vim Awe)!" Dark Vim Master Shougo / My Vim is Dark(neo-plugins) powered. ---------------------------------------------------------------------------------------- -- -- You received this message from the "vim_dev" 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_dev" 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.
