Excerpts from Shougo's message of Tue Dec 31 11:02:02 +0100 2013:
> 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.
lisp is powerful. You're never learning a configuartion only. You're
learning a programming language.
> >- 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++.
I don't think about the "most complicated way you can code in". I want
typed lists/hashmaps etc - and C++ does provide them whereas C does not.
I know that its incredible easy to shoot yourself in the foot using C++.
> Can you write the editor by functional language seriously?
> Editor countains much IO and side effects.
The Haskell way usually only means "separating state and functions".
All the IO stuff is still there. You just have more control when where
it happens. And yes, stuff like editor.buffer[3].addline("foo")
would look much diffferent in Haskell, because you cannot change state
in place, you have to rebuild the containers. But if you do you get undo
for free (as long as you have enough memory ..)
Eg lenses are used to simplify doing such etc. There is also disciple
which tries to allow both. There are many ideas.
> So I think it is impossible.
Yi does already exist. but there is not enough man power. Even JS
highlighting might hang.
> 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.
I am calm - thanks :)
> Because, the repository data is important than clients.
> Are you want to spoil the data?
What do you mean by "spoil"? It would be trivial to make VAM-kr export
the data to any other format.
I agree on that.
> Yes. I want to study other package repository's features.
What for? In the end there are two choices:
1) viml only: you can easily install while running Vim - thinking about
it calling the package manager from vim would doable, too..
2) non viml: you can use existing tools such as pip, ruby gems etc.
They basicall all have a description file telling
- this is pacage foo-2.0
- and it requires bar-1.0 or greater
- and its maintained by XXX
> Can you discuss about it, Mr.Marc?
There is not much to discuss. THere are multiple sources:
- vim-scripts.org (dupliacating vim.sf.net. In the past it was broken for
1-2 month or so causing trouble to users). The authors know about the
PHP API I created, at least in the past they didn't use it (maybe they
do now)
- github
- bitbucket
- other sources
Some users have their plugins at bitbucket and github (& vim.sf.net),
others have it only at one location.
So IMHO the perfect system would allow to register github/bitbucket/
sources and associate mirrors information. Eg this bitbucket/whatsoever
is a mirror of github/foo-bar
Thene there should be a way to export the data, so that you, me and
others can use it.
Even more we should try to have that server mirror the code, so that you
can search it (ventually also adding tests and continuous integration
later if it happens that we have enough resources).
I don't want to rewrite github, but having a code search feature would
be nice.
And there is a last thing to discuss: Does having a single name for
projets make sense? That's what VAM-kr does provide, too.
Does this make sense?
Marc Weber
--
--
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.
