Re: change in Debian emacs policy: make global enabling of add-on lisp packages optional
>
> 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/
--
Reply to: