20 July 2010

My elisp directory conventions

Here are two directory conventions I have found useful in organizing my elisp projects:

Library symbols

I use a convention of setting each subordinate library's symbol as a path-name relative to the main directory (ie, the root lisp directory of the package). For this to work right, load-path only points at the main directory.

For example, a directory structure might look like:

(main directory)
(Name isn't important. load-path only knows about this directory)
my-project-name/
plugins/
foo.el
(provides `my-project-name/plugins/foo')
bar.el
(provides `my-project-name/plugins/bar')
baz.el
(provides `my-project-name/plugins/baz')

I do this because I feel that emacs' namespace is getting crowded and I keep encountering extension library names that try to squeeze project name and library name into one component, like "org-this-thing.el" or "pcmpl-that-thing.el".

This style has the official approval of emacs-devel (I asked) and I know of one other project besides mine that does this (CEDET).

Placement of support libraries

I put testing and other support libraries in a subdirectory with the same name as the library they support. As author of the testing package Emtest, I've found that that works nicely. Just customize uniquify-buffer-name-style so that the various "test.el" buffers get named something clearer than "test.el<2>", "test.el<3>" etc.

Under this convention, part of the directory structure might look like:

my-project-name/
plugins/
foo.el
(the library itself)
foo/
tests.el
(tests pertaining to "foo.el")
testhelp.el
(code that is useful in testing "foo.el" and also useful testing other files that build on "foo.el")
examples
file1
(a file used in tests)
file2
(another file used in tests)
bar.el
bar/
tests.el
(tests pertaining to "bar.el")
(etc)
baz.el
baz/
tests.el
(tests pertaining to "baz.el")
(etc)

No comments:

Post a Comment