Re: change in Debian emacs policy: make global enabling of add-on lisp packages optional
"D. Goel" <deego@gnufans.org> writes:
> 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
> * Installing ilisp makes emacs bind C-c <letter> which broke my .emacs.
> * Installing remem makes emacs bind C-c <letter> which broke my .emacs.
> * Installing html-helper-mode luckily did not break my .emacs but it
> did override some of my C-c <letter> bindings ...
>
> 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.
Agreed. A typical package should not do anything more than add some
autoloads to site-lisp and perhaps munge auto-mode-alist.
> 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.
This sounds like it could cause inconvience as well though; I presume
that _most_ debian emacs users have their own machine, and when they
install an emacs add-on package, they expect it to just start working.
Anyway, a good start would be to just report bugs against emacs add-on
packages that do something stupid (like those you mentioned). Fixing
those problems will help, regardless of whether some additional
mechanism is later added...
-Miles
--
Occam's razor split hairs so well, I bought the whole argument!
Reply to: