In Google’s Summer of Code program, students receive some help while they work for 3 months on the free software project they choose. Several organizations have taken part in the last 4 years, including GNU (ideas for SOC 2009). GNU Emacs could also take part this year; this page is an informal discussion about ideas. Feel free to edit this page! (HowToEdit).
In 2007 it started in 5th March.
In 2008: the program announcement was on 25th February; the start date of applications submission from the mentoring organizations was on 3rd March You can find the dates in 2008 in the timeline. There were 9 days to submit the ideas list, 14 to register as students, and almost 3 months to code.
In 2009 the list of accepted mentoring organizations was published on March 18th. Google started accepting students applications on March 23rd, application deadline was April 3rd. A list of accepted applications was published on the 20th of April.
Coding started on 23rd of May.
If you can guide a student in a particular project, write your name and the project here.
Requisites for the proposals:
After a proposal is here, consult with the community and then send to GNU project's ideas list. That is the page which will be shown to Google.
In the last couple of years, a large number of Integrated Development Environments (IDE’s) has emerged. So far, none has come close to the editing capabilities of Emacs, but on the debugger side, Emacs has been surpassed.
As many people still use Emacs as their preferred editor, an ideal situation would be that Emacs also would be used as a debugger front-end with windows for, say, the call stack, local variables, and breakpoints.
Some work in this area has been done, most notably gdb-ui.el, which provides a multi-window debugging environment for C and C++ and gdb. In addition, the ruby-debug project is doing similar work for Ruby. This project would:
For more information, contact R. Bernstein and Anders Lindgren.
If you know about these topics and you want to help people to improve Emacs, please adapt it, add yourself as a mentor and move the heading to the previous section.
Other sources for ideas are:
See GuileEmacs. At least goal 1 can be aimed.
See CEDET; this is already planned for Emacs 24. This will ease support for other languages and integrate much wanted features like code completion, syntax highlighting, syntax checking, project handling, … Some other tools like JDEE (Java support) or ECB could also be included. Lots of things must be done to make Emacs a better IDE, and this is one of them.
How about also having a proposal for improving VC?
This is much wanted, specially for background processes like checking mail. It is necessary to profit from multicore processors, very common nowadays. There were already attempts to do this. See ConcurrentEmacs and messages in the mailing list (Giuseppe Scrivano, 29 Nov 2008).
There is M-x term, ansi-term, shell, eshell: too many shells, and no one is good enough to please most users.
Emacs has unfinished and sometimes rudimentary tools to track its development. A new GNU project could be established (or existing ones extended) to improve the tools which will serve to sustain Emacs’ coding infrastructure. This could include:
Another change we should ask Google to support is to eliminate the requirement for window and frame sizes to be integral numbers of characters and lines.
Currently, Emacs doesn’t really do well with images that are larger than the window. Improving vertical and horizontal scrolling and being able to switch between window size and actual size should be a considerable improvement.
Bidi support is one of the main things (the only thing?) Emacs lacks to be an universal text editor. If you look at the bidi mailing list (http://lists.gnu.org/mailman/listinfo/emacs-bidi), you find two (aborted) attempts to accomplish this, so it should not be insurmountable.
See RationalElispPackaging. Nowadays each project must provide install instructions, requirements list, update scripts, etc. individually. A packaging system would ease the installation of Emacs components. There is already elpa.
As a sysadmin (and a Debian developer and packager for RPM-based OSs), I hope that any such packaging system will be compatible with existing OS distribution packages.
We have: grep, grep-find, igrep.el (egrep/agrep), rgrep, lgrep, GrepPlus, find-name-dired, find-grep-dired, mgrep, OccurMode, and lots more. See GrepMode. Each one with its particular UI, regexp handling, results displaying, shortcomings, …
We need just one versatile find/grep interface, and obsolete the others for clarity. If it accepts a file name filter and a content filter (both are regexps), it can combine all grep/find functionality.