[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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...

Occam's razor split hairs so well, I bought the whole argument!

Reply to: