Re: Debian's idiosyncratic complexification of Emacs

[Miles Bader <miles.bader@necel.com>]

Geoffrey Teale <tealeg@member.fsf.org> writes:
> On a personal note - I find the idea of subverting the norms of an
> application to reduce usability in a distribution, not increase it.
> Especially where the tool in question (Emacs) is intended for a
> technical audience.
>
> I am certain that the Debian set up is there with the best of intentions
> (just like their Common LISP setup), but nothing has made  me more
> frustrated in a GNU/Linux distribution than the Emacs setup  under
> debian, and anyone of my colleagues at my last employer we  testify to
> that :)

To be fair though, debian has constraints that don't hold for a normal
emacs installation, like the desire to integrate external elisp packages
seamlessly, have multiple versions of emacs installed simultaneously,
and for those two things to not screw each other up.

From what I know (I haven't looked at the details in ages though), I
think their approach is not too bad, though obviously it has warts,
historical and otherwise.  [I've even hacked up my .emacs so I can use
debian elisp packages, which is kind of convenient.]

Given that debian have reasonable goals, and aren't doing anything
egregiously stupid (no comment on that one, just assuming for the
moment... :-), it would be nice if emacs' default mechanisms would aid
what they're doing.  If there are conflicts, I think in many cases that
means emacs' mechanisms should be extended, rather than meaning debian
should give up their goals.

-Miles

-- 
Carefully crafted initial estimates reward you not only with
reduced computational effort, but also with understanding and
increased self-esteem.         -- Numerical methods in C,
  Chapter 9. "Root Finding and Nonlinear Sets of Equations"