google summer of code
Anurag Priyam
In a discussion with current maintainers of vim.org regarding site
re-write/re-thinking the topic of participating in Google Summer of
Code was raised, and I feel that further discussion (if happening)
should take place on this list.
A bit of Googling reveals that Vim did not participate after 2008. We
will need to move fast if we intend to apply as Google has started
accepting applications from mentoring organizations and the deadline
is 11th March.
Some ideas (most of them copied from Marc's email with slight editing)
that might serve a GSoC:
* improve VimL a little bit (maybe adding closures, improving stack
traces, ..) Also make it easier to bind ruby, python, .. code to
mappings directly.
* Maybe add native curl support so that vim-addon-manager can be
installed without much user interaction on Windows (without having to
pull curl or the like first ..)
* Improving the signs implementation. Different scripts can use same
sign id by accident. So this is a design flaw. Also, signs which don't
move if you add lines. (Eg for breakpoints when using php xdebug ...)
Maybe one can get this done using events as well but its less optimal.
* Vim.org redesign
Since, I am not qualified to act on behalf of Vim, I will leave it to
the upstream to take if from here :). Just for a start, we would need
volunteers for organization admin, mentors for ideas, and maybe more
ideas.
--
Anurag Priyam
http://about.me/yeban/
ZyX
sent 21:34:07 08 March 2011, Tuesday
by Anurag Priyam:
> * Improving the signs implementation. Different scripts can use same
> sign id by accident. So this is a design flaw. Also, signs which don't
> move if you add lines. (Eg for breakpoints when using php xdebug ...)
> Maybe one can get this done using events as well but its less optimal.
There are lots of places where plugins may use same id by accident (functions,
mappings, variables, ...). There is another point: I was going to add signs
support to my format.vim plugin, but the following facts stopped me:
1. signs are accessible only with commands;
2. command output (which I may parse) is translated;
3. v:lang variable value is system-dependent.
Another suggestion for GSoC: make vim able to differentiate between <CR> and
<C-m> and make it possible to map something like <C-Tab> at least in GUI (these
features are discussed on vim-dev now, see the long «Dear Bram» thread).
Original message:
Marc Weber
support to my format.vim plugin, but the following facts stopped me:
> 1. signs are accessible only with commands;
> 2. command output (which I may parse) is translated;
Can you give vim-addon-signs a try?
The idea is to declaratively tell Vim only about the state of signs
which must be placed.
All the update handling is done by the plugin.
This assumes that you have less than a million of signs to place though.
This got rid of the annoying cumbersome api.
But you're right rtp being a setting is bad. THere should be
setRTPList() and getRTPListk functions etc.
> 3. v:lang variable value is system-dependent.
Didn't knew about this being a problem
Can you elaborate a little bit in which cases this bothers you
implementing signs?
Marc Weber
Charles Campbell
> [snip]
>
> Some ideas (most of them copied from Marc's email with slight editing)
> that might serve a GSoC:
>
I'd like an improvement to the plugin debugging: the ability to
watchpoint expression(s). For those who don't know gdb, that means: if
the expression changes value, stop executing the plugin at that point.
Regards,
Chip Campbell
Thomas Hume
Another suggestion for GSoC: make vim able to differentiate between <CR> and
<C-m> and make it possible to map something like <C-Tab> at least in GUI (these
features are discussed on vim-dev now, see the long «Dear Bram» thread).
Ernie Rael
On 3/8/2011 10:34 AM, Anurag Priyam wrote:
> Some ideas (most of them copied from Marc's email with slight editing)
> that might serve a GSoC:
>
Does the faster re still need tests and "final" integration?
Anurag Priyam
> the upstream to take if from here :). Just for a start, we would need
> volunteers for organization admin, mentors for ideas, and maybe more
> ideas.
I have started a wiki page [1] to collect and refactor the ideas.
[1] http://vim.wikia.com/wiki/Vim_GSoC_2011_Ideas
ZyX
sent 00:28:28 09 March 2011, Wednesday
by Marc Weber:
> Why do you want to parse it?
<...>
> Didn't knew about this being a problem
> Can you elaborate a little bit in which cases this bothers you
> implementing signs?
format.vim is an extensible text-to-markup (html/bbcode/latex, though only html
targed is full-featured) translator. I do not want to place any signs, I want to
get already placed by other plugins.
> Can you give vim-addon-signs a try?
I will probably read its code when I will create frawor/signs.vim module, but it
definetly won't help me in getting signs placed by plugins that do not use vim-
addon-signs.
Original message:
Christian Brabandt
> In a discussion with current maintainers of vim.org regarding site
> re-write/re-thinking the topic of participating in Google Summer of
> Code was raised, and I feel that further discussion (if happening)
> should take place on this list.
That sounds like a good idea. I'd like to see some work on the todo list.
regards,
Christian
Lech Lorens
> Some ideas (most of them copied from Marc's email with slight editing)
> that might serve a GSoC:
I would like to propose a feature that was discussed here about a year ago.
An excerpt from todo.txt which describes it:
8 Use a mechanism similar to omni completion to figure out the kind of tab
for CTRL-] and jump to the appropriate matching tag (if there are
several).
Alternative: be able to define a function that takes the tag name and uses
taglist() to find the right location. With indication of using CTRL-] so
that the context can be taken into account. (Robert Webb)
I did some development then. The feature together with VimL code from
Robert Webb has been a great improvement during my work since then.
However, I ceased the development when I discovered I would need to make
significant modifications to existing Vim code which would probably prevent
the patch from being accepted upstream. I think with a blessing from Bram
Vim could benefit from smart tagging.
If this feature gets accepted and anyone is interested in working on it,
I would be happy to become a mentor.
--
Cheers,
Lech
Anurag Priyam
[...]
> Since, I am not qualified to act on behalf of Vim, I will leave it to
> the upstream to take if from here :). Just for a start, we would need
> volunteers for organization admin, mentors for ideas, and maybe more
> ideas.
Its sad, but since we did not have any volunteers for mentors, or
co-admin Vim did not apply for GSoC.
Thanks all for all your suggestions and efforts.