From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/44422 Path: main.gmane.org!not-for-mail From: Harry Putnam Newsgroups: gmane.emacs.gnus.general Subject: Re: Autoloads no longer working? Date: Fri, 26 Apr 2002 10:11:09 -0700 Sender: owner-ding@hpc.uh.edu Message-ID: References: <877kmvups8.fsf@glaurung.green-gryphon.com> <87pu0mu6it.fsf@glaurung.green-gryphon.com> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1019841310 29637 127.0.0.1 (26 Apr 2002 17:15:10 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 26 Apr 2002 17:15:10 +0000 (UTC) Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 1719JO-0007ht-00 for ; Fri, 26 Apr 2002 19:15:10 +0200 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1719Hx-00041y-00; Fri, 26 Apr 2002 12:13:41 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 26 Apr 2002 12:13:53 -0500 (CDT) Original-Received: from sclp3.sclp.com (qmailr@sclp3.sclp.com [209.196.61.66]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id MAA11999 for ; Fri, 26 Apr 2002 12:13:39 -0500 (CDT) Original-Received: (qmail 3513 invoked by alias); 26 Apr 2002 17:13:10 -0000 Original-Received: (qmail 3508 invoked from network); 26 Apr 2002 17:13:10 -0000 Original-Received: from 66-51-205-200.dslextreme.com (HELO mail.dslextreme.com) (66.51.205.200) by gnus.org with SMTP; 26 Apr 2002 17:13:10 -0000 Original-Received: from reader.local.lan (adsl-66.51.210.228.dslextreme.com [66.51.210.228]) by mail.dslextreme.com (8.12.2/8.12.2) with ESMTP id g3QHErwM007155 for ; Fri, 26 Apr 2002 10:14:54 -0700 Original-Received: (from root@localhost) by reader.local.lan (8.11.6/8.11.6) id g3QHCBP07757 for ding@gnus.org.PROCMAIL; Fri, 26 Apr 2002 10:12:11 -0700 Original-Received: (from reader@localhost) by reader.local.lan (8.11.6/8.11.6) id g3QHBlW07713; Fri, 26 Apr 2002 10:11:47 -0700 X-Authentication-Warning: reader.local.lan: reader set sender to reader@newsguy.com using -f Original-To: ding@gnus.org In-Reply-To: (Kai.Grossjohann@CS.Uni-Dortmund.DE's message of "Fri, 26 Apr 2002 17:01:47 +0200") User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i586-pc-linux-gnu) Original-Lines: 45 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:44422 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:44422 Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes: > Andreas Fuchs writes: > >> Today, Kai Großjohann wrote: >>> I think there's a reason for url.el to require mailcap. And >>> mailcap.el comes with url. So this is a problem only when >>> considering the interaction of packages. >> >> No, on this system, it doesn't. I'm using the latest version of >> url-w3-e21, and the only mailcap.el I have lying around is the one that >> comes with the two gnusae I have installed (emacs's and my cvs install). > > Hm. How come? > >>> I wonder if Debian could allow users to frob the load-path before the > ^^^^^ >>> standard w3 package is loaded? Maybe read a file ~/.emacs.first, if >>> it exists? >> >> It does already, by having an /etc/emacs/site-start.el, but that's not >> what powerless users can modify. Root must do this. (-: > ^^^^ > > That's what I'm saying... I ran into something kind of similar on a Debian system too. I wasn't aware of debians emacs policy and had already installed the debian package emacs21.1 I put my site stuff in /usr/local/share/emacs/site-lisp/site-start.el but it was ignored and I couldn't figure out why at first. Finally I noticed the load-path variable started with /etc/emacs/site-start.el So it had already loaded (a blank) site file and was ignoring mine. the non-default path was apparently set during compile. I had root so it wasn't a problem, but I did notice one could still load site-start.el type stuff from /usr/share/emacs/site-lisp/default.el, even though /etc/emacs/site-start.el had already been frobbed. Maybe an arrangement where emacs looks for ~/.default.el would help?