In Google's [http://code.google.com/soc 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 ([http://www.gnu.org/software/soc-projects/ideas.html 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]]). == How to participate; the basics == Detailed info in the [http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs FAQs]. Use also the chat channel #gsoc on [http://freenode.net Freenode]. === Dates and deadlines === In 2007 it started in 5th March. ==== 2008 === 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 [http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline timeline]. There were 9 days to submit the ideas list, 14 to register as students, and almost 3 months to code. ==== 2009 ==== In 2009 the list of [http://socghop.appspot.com/program/accepted_orgs/google/gsoc2009 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. === People === We need: * mentors, which follow students' progress and help them. Each project needs a mentor. * students which have interest on a particular project. They must be taking official studies. They will work approx. from May to August. === Legal === Since students will write code for [[GnuEmacs]], they must sign first an agreement with the FSF. See [[LegalMatters]]. == Firm list of ideas (with mentors) == If you can guide a student in a particular project, write your name and the project here. Requisites for the proposals: * the goal is to write code, not documentation * adapt the difficulty to 12 weeks of work * they should fit the GNU project; that means: they should steer people to use free platforms and programs * please list here only the projects with mentor; for loose ideas and brainstorming, see the next section After a proposal is here, consult with the community and then send to [http://www.gnu.org/software/soc-projects/ideas.html GNU project's ideas list]. That is the page which will be shown to Google. === shell and script debuggers and Emacs === ([http://www.gnu.org/software/soc-projects/ideas.html#shelldbg source]) 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: * define guidelines for the look and feel for multi-window debugger Emacs environments. * refactor and unify the existing code base (gdb-ui and rdebug), to make it easier to implement support for other debuggers. * Analyze the underlying Emacs layers [1], and maybe restructure parts. Especially, the gud.el layer is a candidate for this. * Implement support for other languages and/or debuggers, for example Bash and Python. For more information, contact R. Bernstein and Anders Lindgren. == Loose ideas and discussion == 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: * the [[WishList]]. You can extract and define a project based on the wishes there * [[EmacsIDEWishList]], particularly important improvements * [[EmacsBugs]] * [[EmacsTodo]]: fixing a subset of those tasks would be instructive and helpful === Make Scheme an Emacs extension language === See [[GuileEmacs]]. At least goal 1 can be aimed. === Integrate CEDET into Emacs === 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. === Improve VC (version control system) === How about also having a proposal for improving VC? Improve dealing with branches and add other features that are needed for modern version control systems. === Good multithreading support for Emacs === 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). === Create an usable shell interface === There is M-x term, ansi-term, shell, eshell: too many shells, and no one is good enough to please most users. * [[AnsiTerm]] and [[ShellMode]] could be merged so that we have just 2 types of shell: an Elisp one ([[Eshell]]) and an interface to your other shell (like bash). * Eshell could also have all good things by default: colors, completion, globbing, ... See [[EshellWishlist]] * Compatibility should be checked so that all programs work normally; just like in bash inside an xterm * Performance issues: cat, ls, find, ... should run fast === Integrated version control system and bug tracker to be used in Emacs project === 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: * setting the Bazaar repository, migrating from CVS to Bazaar and adapting Bazaar so that it fits Emacs * web interface to the bug tracker, similar to the other projects like Bugzilla and Launchpad, where you could see reports, send a new bug, query for bugs, ... * and at the same time, mail interface, where you can issue all commands just via mail * integration between VC and bug tracker; similar to what Bundle Buggy (in Launchpad) does: patch tracking, asking for automatic merges from the mailing list, patch approval, ... * some other infrastructure tasks could be added, like automatic building (continuous integration), breakage detection (get noticed when code doesn't compile), validation at commit time, ... === Finer dimensions for window and frame sizes === 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. === Multiple major modes === Integrate [[MuMaMo]] into Emacs so that it is easy to have more than one major mode in a buffer; for instance: Java and HTML (that's .jsp) or [[OrgMode]]+C/Lisp/Python/Java/... === Port to GNUstep === Improve port to OpenStep (both for [http://www.gnustep.org/ GNUStep] and MacOS X). See [[EmacsApp]]. The main part would be to get the dump to work. There are also issues with incorrect font displaying. === Image Display === 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. === Right to Left Writing === 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. === Create an Emacs package distribution system === 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 [http://tromey.com/elpa/ 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. === Integrate the many searching engines (find/grep) into one tool === 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. == Accepted Emacs-related projects == * [[GDB-MI|Emacs GDB/MI migration]] * GuileEmacs (in 2009, 2010 and 2011) ---- CategoryWishList