"D. Goel" <[EMAIL PROTECTED]> 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!
