All my machines have been running persistent Emacs daemons for some time now. Every time I edit a web-page text area or a tweak a configuration file the Emacs client whizzes me to the file with efficient enthusiasm.
However I’m still running individual sessions for each “project” I work on. For example at work I currently have one for the main source tree, one for the standalone Java project and one for a kernel I’m working on. This is in no small part due to the rather basic project support I hacked up some time ago.
While conceptually switching my various project variables to be buffer locals would solve a lot of problems there would be a mess of smarts to improve on and I currently can’t justify the diversion. I’ve attempted to get things like CEDET and JDEE working before but with limited success. They all seem overly heavy-weight solutions to the things I’d like it to achieve:
- Associate new open files with the “project” they are in
-
Make M-x compile do the right thing:
- Select compile command from per-project compile history
- Separate compile window for each project
- Make M-x find-tag behave in the project context
As I say simple needs. Once I have all that working then current pain points like having multiple IRC channels over multiple instances of Emacs can go away and everything is literately only a few key-strokes away.
Dear lazyweb, what lightweight project management tools exist out there and which are really good?
EDIT TO ADD: I’m going to have a look at eproject. Other suggestions still welcome though 
Directory locals work for me. I use them for a couple of Perl projects. It’s probably the most lightweight option out there, since it’s in emacs core and it only requires creating one file per project. Documentation here: http://www.gnu.org/software/emacs/manual/html_node/emacs/Directory-Variables.html
I just use them to redefine compile-command to run unit tests from the project’s root directory, and set tags-file-name to the correct TAGS file.
Hmm, looks like like I could do most of what want with that. If only I had the more useful functions from 23.2 :-/
I’ve used mkproject with ease for some time. http://www.emacswiki.org/emacs/mk-project.el
Let’s you easily define projects with etags, ack, and grep support. Everything’s done succintly in elisp and loaded quickly with a couple keystrokes.
I finally got around to documenting all the configuration options for mk-project. See the new and improved README at http://github.com/mattkeller/mk-project/. Comments and suggestions on mk-project are most welcome. Contact me at mattkeller [gmail].
Cheers,
Matt
Thanks for that, I shall have a look with interest.
I’m torn between statically defining projects as mk-project does or defining types of project like eproject does. What I like about the second approach is the ability to define a project that looks for certain files (e.g. “AndroidManifest.xml”) and then automatically pick up the settings and attributes for a generic Android project.
Is it possible to emulate that behaviour with mk-project or is it orthogonal to the design?
Mk-project is coded such that only one project is active at any one time. The documentation (and my own use!) is biased toward pre-defining projects. However, it should be straight forward to write a function that examines the current buffer (and files up and down the file hierarchy) and decides if it wants to start a new dynamically defined mk-project. The project-def and project-load functions can be called by a hook function, not just interactively.
I use both escreen and projects.el from emacs-goodies-el debian package. The former allow for having nice visual separation of tasks and the latter for handling buffer names and IBuffer sorting.
Then escreen could be extended to support some more “screen” local settings, I’ve read, so I think you could handle a M-x compile history per screen and compile window. Ditto for find-tag. That’s the way I’d go if I was using M-x compile
Note I have extensive tools atop projects.el to ease the setup, and some escreen setup to share too. Ask if you’re interrested.