Re: elisp: isn't default-directory always the dir of current file??

[Mike Mattie]

On Mon, 2 Mar 2009 12:32:58 -0800 (PST)
Xah Lee <xahlee@gmail.com> wrote:

> On Mar 2, 2:32 am, Lennart Borgman <lennart.borg...@gmail.com> wrote:
> > On Mon, Mar 2, 2009 at 8:46 AM,XahLee<xah...@gmail.com> wrote:
> > >> but that didn't. The following works though:
> > >> (add-to-list 'load-path (file-name-directory load-file-name))
> >
> > > Ugh, this is quite painful. Spend 2+ hours on this.
> >
> > > If i use this:
> > > (add-to-list 'load-path (file-name-directory load-file-name))
> >
> > > it works if the file is loaded by elisp. But doesn't work if the
> > > file is run with eval-buffer.
> >
> > Use buffer-file-name if load-file-name is nil.
> 
> Thanks.
> 
> ---------------
> 
> For completeness or whoever may be reading this later, here's the code
> to put the dir into load path:
> 
> (add-to-list 'load-path
>  (file-name-directory (if load-file-name load-file-name buffer-file-
> name)))
> 
> 
> This is useful, because suppose you have a elisp library of many files
> in a dir named xyz. And in that dir there's one file that init them
> all, named “init.el”.
> 
> In your install instruction, you can tell user to open init.el and
> eval-buffer and everything is installed. And if user wants it
> automatically loaded when emacs starts, just put a single line such
> as:
> 
> (load-file "/Users/xah/web/emacs/emacs2/init.el")
> 
> in “.emacs”.
> 
> The advantage of this is that:
> 
> • user can just put a single load-file line to init your library. They
> don't need to put extra line to add path to load-path.
> 
> • user can install your library in a very simple way of opening the
> file and M-x eval-buffer. (which is simple and especially when user
> want to see what your lib do first).
> 
> ... there are probably other easy alternatives for installation
> approach...
> 
> For example, 2 installation instruction from existing package i find
> very good are:
> 
> ; from nxml
> (load-file "~/Documents/emacs/nxml-mode-20041004/rng-auto.el")
> 
> ; from js2
> (autoload 'js2-mode "js2" nil t)
> 
> Very excellent!
> 
> Often, emacs packages does not have good install instruction. Some,
> simply say “put dir in your load path”, assuming that the user knows
> about elisp. Many users have no idea about load path or the concept
> particular to elisp.
> 
> some rambling thoughts about emacs library system below.
> ----------------------------------
> 
> Also, emacs itself doesn't have a simple, mechanical, uniform
> installation system. It would be nice if it does. Something enforced
> by elisp... so that all packages are forced to have one single
> installation method, such as say “(install filename)”.
> 
> ... elisp's concept of module, lib, package etc are also sucky. Here's
> something i wrote in my tutorial:
> 
> What's Library, Package, Feature?
> 
> Here's a bit technical detail about some elisp issues related to
> library. Knowing it helps you a bit.
> 
> Emacs lisp the language does not have name spaces. Everything is
> global. Also, emacs has a concept of “package”, “library”, but these
> terms are used losely in the documentation. They do not have technical
> meaning in emacs lisp. Emacs also has a concepts of “feature”. A
> “feature” does have technical meaning in elisp. It is basically a
> elisp symbol, that can be added to the list variable “features”. The
> sole purpose is for emacs to know which “feature” has been loaded
> already. A emacs “feature” has no relation to the file name the lisp
> symbol is in.
> 
> In general, the terms used by emacs: “package”, “library”, “feature”,
> are all fuzzily defined and confusing, and none enforces a relation to
> a file's name. This means, you could have a file named “xyz.el”, which
> provides a feature named “abc”, while it really just provide a mode to
> user with the command name “opq-mode”, and “opq-mode” might have
> display name “opq” or “OPQ”, “OPQ mode”, or “yoyo”. And, this file can
> be considered as a package as well as library
> 
>   Xah
> ∑ http://xahlee.org/
> 
> ☄

I am not sure if it is 100% on target to your goals but there is a uniform 
system. It is Tromney's ELPA
package management system. http://tromey.com/elpa/

It is quite sophisticated addressing the issues of package management 
comprehensively. As for load-path
there are endless variations on tweaking load-path. I decided to ditch the 
ad-hoc approach and go with
something systematic. To that end I created GRAIL, a configuration loader that 
aims to put an end
to the endless ad-hoc load-path tweaking. It works well for my purposes, but I 
have published it so that
other people may use it, for reading, or direct use.

GRAIL: http://www.emacswiki.org/emacs/Grail

Cheers,
Mike Mattie