> > A typical emacs package has little effect unless you explicitly invoke it.
While that is supposed to be true, it has been very untrue in practice, IME. Here are some examples of the top of my head: * Installing maxima makes my emacs N new functinos with ~ N namespaces, and N is very large. * Installing ilisp makes emacs bind C-c <letter> which broke my .emacs. * Installing remem makes emacs bind C-c <letter> which broke my .emacs. Remem did allow the user to override this binding in .emacs, but that either means that each user should have to change their .emacs just because the admin decided to install remem, or that the sysadmin should have to modify init files. * Installing html-helper-mode luckily did not break my .emacs but it did override some of my C-c <letter> bindings (though, luckily, only in the html-helper-mode) which it is not supposed to do. thus, these packages, instead of being mere additions to site-lisp, placed files in site-init which breaks emacs conventions. It would be nice if debian would require each emacs package which seeks to "modify the default emacs" to please follow emacs conventions as well. Moreover, they should not break emacs conventions even if they "merely add themselves to site-lisp" and leave the site-init alone. Of course, similar to Faheem, it remains a wishlist of mine (and i am foggy on how it can be implemented) to recognize that since in practice, many packages will err about following emacs conventions, they should somehwo be "disabled" unless a user requests. > The major exception is probably patterns added to `auto-mode-alist' > -- and that only seems to be a problem if there's a conflict. DG http://deego.gnufans.org/~deego/ --
