Autoloads no longer working?

Autoloads no longer working?

[Andreas Fuchs]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

Hi,

I'm experiencing very strange problems with gnus. Before, an

(autoload 'gnus "gnus" "" t)

was enough to make gnus start up right. Now, I have to manually load
mm-util, gnus-util so that gnus actually starts up, and various "rfc"
packages, to read articles (e.g. with xfaces in them).

I have tried upgrading my gnus (I am using CVS gnus as of 3 days ago),
but that didn't change anything. I think that emacs (21.2.1, debian
unstable) was upgraded before it stopped working. Is that a problem of
emacs or one of gnus's?

Thanks,
-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

[-- Attachment #2: Type: application/pgp-signature, Size: 231 bytes --]

Re: Autoloads no longer working?

[Kai Großjohann]

Andreas Fuchs <asf@void.at> writes:

> I'm experiencing very strange problems with gnus. Before, an
> (autoload 'gnus "gnus" "" t)

What happens when you leave that out?  I think Gnus should be
autoloaded by default.

Maybe the problem happens when you are processing ~/.gnus?

kai
-- 
Silence is foo!

Re: Autoloads no longer working?

[Andreas Fuchs]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

Today, Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> wrote:
> What happens when you leave that out?  I think Gnus should be
> autoloaded by default.

Should it? Changed that, I don't notice any change.

Btw, I noticed that there are some features that are (require ')d in
other files; some of these features were present, but their code was not
loaded, I had to (load) them myself.

> Maybe the problem happens when you are processing ~/.gnus?

Actually, I noticed that these happen before the ~/.gnus gets loaded: I
only get these messages:

,----
| Loading gnus...
| eval: Symbol's function definition is void: mm-guess-mime-charset
`----

Thanks for your help,
-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

[-- Attachment #2: Type: application/pgp-signature, Size: 231 bytes --]

Re: Autoloads no longer working?

[Kai Großjohann]

Andreas Fuchs <asf@void.at> writes:

> Btw, I noticed that there are some features that are (require ')d in
> other files; some of these features were present, but their code was not
> loaded, I had to (load) them myself.

Are you sure you aren't mixing Gnus versions?  For example, it does
not work to (add-to-list 'load-path "~/path/to/gnus/lisp/") from the
~/.gnus file, as most of Gnus has been loaded already by that time.

You might wish to locate the statement that adds the new Gnus version
to load-path and put (message "XXX %s" features) before that.  Then you
can start Emacs and search the *Messages* buffer for XXX and see if
any Gnus features ("^gnus", "^nn", "^message", "^mailcap") are
present.  If this happens, you frobbed load-path too late.

kai
-- 
Silence is foo!

Re: Autoloads no longer working?

[Andreas Fuchs]

[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]

On 2002-04-23, Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> wrote:
> Andreas Fuchs <asf@void.at> writes:
> 
>> Btw, I noticed that there are some features that are (require ')d in
>> other files; some of these features were present, but their code was
>> not loaded, I had to (load) them myself.
> 
> Are you sure you aren't mixing Gnus versions?  For example, it does
> not work to (add-to-list 'load-path "~/path/to/gnus/lisp/") from the
> ~/.gnus file, as most of Gnus has been loaded already by that time.

I add the path as soon as possible; Even when I start emacs with -q, the
features are present. Could that be a debian emacs bug?

It seems like emacs21's gnus gets loaded (or rather, provided) before I
can do anything about it.

> You might wish to locate the statement that adds the new Gnus version
> to load-path and put (message "XXX %s" features) before that.  Then
> you can start Emacs and search the *Messages* buffer for XXX and see
> if any Gnus features ("^gnus", "^nn", "^message", "^mailcap") are
> present.  If this happens, you frobbed load-path too late.

See above, it doesn't seem to matter when load-path gets frobbed. Is
this default emacs behaviour? I can't seem to find any reference to it
in the debian-local configuration in /etc/emacs*.


-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

[-- Attachment #2: Type: application/pgp-signature, Size: 231 bytes --]

Re: Autoloads no longer working?

[Paul Jarc]

Andreas Fuchs <asf@void.at> wrote:
> On 2002-04-23, Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> wrote:
>> Are you sure you aren't mixing Gnus versions?  For example, it does
>> not work to (add-to-list 'load-path "~/path/to/gnus/lisp/") from the
>> ~/.gnus file, as most of Gnus has been loaded already by that time.
>
> I add the path as soon as possible; Even when I start emacs with -q, the
> features are present. Could that be a debian emacs bug?

Probably some parts of Gnus are being loaded from site-start.el.  So
start Emacs with --no-site-file and then after frobbing load-path,
explicitly load site-start in your .emacs.


paul

Re: Autoloads no longer working?

[Kai Großjohann]

Andreas Fuchs <asf@void.at> writes:

> I add the path as soon as possible; Even when I start emacs with -q, the
> features are present. Could that be a debian emacs bug?

Ayee.  I think Debian has /etc/emacs/site-start.d which contains
files which might load Gnus.

Hm.

You could frob the files in that directory (add `message' statements)
to find out which one leads to Gnus being loaded.  Then you can
follow that trail.

You know, Gnus has to be loaded _somewhere_.

If "emacs -q -no-site-file" also has Gnus, then it's already dumped
into the executable, which is not a good idea, IMHO.

kai
-- 
Silence is foo!

Re: Autoloads no longer working?

[Andreas Fuchs]

On 2002-04-24, Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE>
wrote:
> Andreas Fuchs <asf@void.at> writes:
> 
>> I add the path as soon as possible; Even when I start emacs with -q,
>> the features are present. Could that be a debian emacs bug?
> 
> Ayee.  I think Debian has /etc/emacs/site-start.d which contains
> files which might load Gnus.

Tested it:

emacs -q -no-site-file # doesn't have gnus loaded

emacs -q -no-site-file # with (debian-startup 'emacs21) evaluated
                       # doesn't have gnus loaded

emacs -q -no-site-file # with (debian-startup 'emacs) evaluated
                       # doesn't have gnus loaded, either!

emacs -q               # has gnus loaded.

This is very strange, and I have no idea where this sucker could be
loaded. My only choice is removing the gnus directory in my emacs lisp
installation and trying to find out where the backtrace appears. (-:

> Hm.
> 
> You could frob the files in that directory (add `message' statements)
> to find out which one leads to Gnus being loaded.  Then you can
> follow that trail.
> 
> You know, Gnus has to be loaded _somewhere_.

I know. And that's what is confusing me.. somewhere along that path,
gnus gets loaded, but I have no idea where.

Thanks for your help,
-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

Re: Autoloads no longer working?

[Manoj Srivastava]

>>"Kai" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

 Kai> Andreas Fuchs <asf@void.at> writes:
 >> I add the path as soon as possible; Even when I start emacs with -q, the
 >> features are present. Could that be a debian emacs bug?

 Kai> Ayee.  I think Debian has /etc/emacs/site-start.d which contains
 Kai> files which might load Gnus.

	The file you are thinking about is installed by the standalone
 gnus package in Debian, and not by the various flavours of emacsen.

	Specifically, the file is /etc/emacs20/site-start.d/20gnus-init.el.
 It is not installed for emacs21. And when it is run for emacs20, the
 first thing it does to put the file path for the standalone gnus at
 the beginning of the load path.

	I am running oort gnus (as you can see from the headers) on
 Debian with emacs21, and I have no problems with autoloads; I do not
 think this is a just a simple Debian issue.

	manoj
-- 
 Never volunteer for anything. Lackland
Manoj Srivastava   <srivasta@acm.org>  <http://www.datasync.com/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Autoloads no longer working?

[Andreas Fuchs]

[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]

On 2002-04-25, Manoj Srivastava <srivasta@acm.org> wrote:
> 	The file you are thinking about is installed by the standalone
>  gnus package in Debian, and not by the various flavours of emacsen.
> 
> 	Specifically, the file is
> 	/etc/emacs20/site-start.d/20gnus-init.el.
>  It is not installed for emacs21. And when it is run for emacs20, the
>  first thing it does to put the file path for the standalone gnus at
>  the beginning of the load path.

Strange, in my emacs installation, there is a
/usr/share/emacs21/lisp/gnus directory, which even contains files. It
seems like gnus-start from there gets loaded. My emacs installation
looks like:

,----
| ~ $ dpkg -l gnus emacs21 emacs21-el
| Desired=Unknown/Install/Remove/Purge/Hold
| | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
| |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
| ||/ Name           Version        Description
| +++-==============-==============-============================================
| pn  gnus           <none>         (no description available)
| ii  emacs21        21.2-1         The GNU Emacs editor.
| ii  emacs21-el     21.2-1         GNU Emacs LISP (.el) files.
`----

As you can see, I have no gnus installed (gnus-bonus-el has the same
status as has gnus). I'm running out of ideas.

>  I am running oort gnus (as you can see from the headers) on
>  Debian with emacs21, and I have no problems with autoloads; I do not
>  think this is a just a simple Debian issue.

I agree in that this problem is not a simple one; but I do think this is
a debian issue (see my previous mail - when I suppress loading of the
user config file (I never touch my system-wide config), gnus features
are present).

Thanks,
-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

[-- Attachment #2: Type: application/pgp-signature, Size: 231 bytes --]

Re: Autoloads no longer working?

[Andreas Fuchs]

[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]

On 2002-04-25, Manoj Srivastava <srivasta@acm.org> wrote:
> 	The file you are thinking about is installed by the standalone
>  gnus package in Debian, and not by the various flavours of emacsen.
> 
> 	Specifically, the file is
> 	/etc/emacs20/site-start.d/20gnus-init.el.
>  It is not installed for emacs21. And when it is run for emacs20, the
>  first thing it does to put the file path for the standalone gnus at
>  the beginning of the load path.

Strange, in my emacs installation, there is a
/usr/share/emacs21/lisp/gnus directory, which even contains files. It
seems like gnus-start from there gets loaded. My emacs installation
looks like:

,----
| ~ $ dpkg -l gnus emacs21 emacs21-el
| Desired=Unknown/Install/Remove/Purge/Hold
| | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
| |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
| ||/ Name           Version        Description
| +++-==============-==============-============================================
| pn  gnus           <none>         (no description available)
| ii  emacs21        21.2-1         The GNU Emacs editor.
| ii  emacs21-el     21.2-1         GNU Emacs LISP (.el) files.
`----

As you can see, I have no gnus installed (gnus-bonus-el has the same
status as has gnus). I'm running out of ideas.

>  I am running oort gnus (as you can see from the headers) on
>  Debian with emacs21, and I have no problems with autoloads; I do not
>  think this is a just a simple Debian issue.

I agree in that this problem is not a simple one; but I do think this is
a debian issue (see my previous mail - when I suppress loading of the
user config file (I never touch my system-wide config), gnus features
are present).

Thanks,
-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

[-- Attachment #2: Type: application/pgp-signature, Size: 231 bytes --]

Re: Autoloads no longer working?

[Kai Großjohann]

Manoj Srivastava <srivasta@acm.org> writes:

> 	Specifically, the file is /etc/emacs20/site-start.d/20gnus-init.el.
>  It is not installed for emacs21. And when it is run for emacs20, the
>  first thing it does to put the file path for the standalone gnus at
>  the beginning of the load path.

20gnus-init.el is a good thing.  Otherwise it wouldn't work to use
the standalone Gnus package.

I'm sorry if "ayee" created the wrong connotations.  I don't know
what does 20gnus-init.el do, but I guess it only frobs load-path.
The problem is that part of Gnus is actually _loaded_.  I don't
understand how that happens, but only Andreas can find out...

kai
-- 
Silence is foo!

Re: Autoloads no longer working?

[Manoj Srivastava]

>>"Kai" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

 Kai> I don't know what does 20gnus-init.el do, but I guess it only
 Kai> frobs load-path.

	This is the content of that file:
======================================================================
(if (file-exists-p (concat "/usr/share/"
			   (symbol-name debian-emacs-flavor)
			   "/site-lisp/gnus/gnus.elc"))
    (progn
      (provide 'gnus-init)
      (if (fboundp 'debian-pkg-add-load-path-item)
	  (setq load-path (debian-pkg-add-load-path-item (concat "/usr/share/"
						 (symbol-name 
						  debian-emacs-flavor)
						 "/site-lisp/gnus")))
	(setq load-path (cons (concat "/usr/share/"
				      (symbol-name debian-emacs-flavor)
				      "/site-lisp/gnus") load-path)))
      ))
======================================================================

debian-pkg-add-load-path-item is a compiled Lisp function in `debian-startup'.
(debian-pkg-add-load-path-item ITEM)

Takes a path item (a string) and adds it to load path in the
correct position for an add-on package, before the emacs system
directories, but after the /usr/local/ directories.  After modifying
load-path, returns the new load-path.
======================================================================

	manoj
	
-- 
 The use of anthropomorphic terminology when dealing with computing
 systems is a symptom of professional immaturity. Edsger Dijkstra
Manoj Srivastava   <srivasta@acm.org>  <http://www.datasync.com/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Autoloads no longer working?

[Kai Großjohann]

Andreas Fuchs <asf@void.at> writes:

> On 2002-04-25, Manoj Srivastava <srivasta@acm.org> wrote:
>> 	The file you are thinking about is installed by the standalone
>>  gnus package in Debian, and not by the various flavours of emacsen.
>> 
>> 	Specifically, the file is
>> 	/etc/emacs20/site-start.d/20gnus-init.el.
>>  It is not installed for emacs21. And when it is run for emacs20, the
>>  first thing it does to put the file path for the standalone gnus at
>>  the beginning of the load path.
>
> Strange, in my emacs installation, there is a
> /usr/share/emacs21/lisp/gnus directory, which even contains files. It
> seems like gnus-start from there gets loaded.

We were talking about /etc/emacs*/site-start.d, not
/usr/share/emacs21/lisp/gnus...

Here's a way to find out what's happening:

* delete gnus-start.elc (actually, just rename it)
* put (debug) near the beginning of the file gnus-start.el

Then start Emacs.  You should get a backtrace.  From this backtrace,
it should be possible to see which code loads it.

Also, you can put (message "foo") statements in various places in the
site-wide init files to see what's happening.

kai
-- 
Silence is foo!

Re: Autoloads no longer working?

[Manoj Srivastava]

>>"asf" == Andreas Fuchs <asf@void.at> writes:

 asf> Strange, in my emacs installation, there is a
 asf> /usr/share/emacs21/lisp/gnus directory, which even contains files. It
 asf> seems like gnus-start from there gets loaded. My emacs installation
 asf> looks like:

	There is something very wrong with your load-path, then.

 >> ii  emacs21        21.2-1         The GNU Emacs editor.
 >> ii  emacs21-el     21.2-1         GNU Emacs LISP (.el) files.

	Same here.

 asf> I agree in that this problem is not a simple one; but I do think this is
 asf> a debian issue (see my previous mail - when I suppress loading of the
 asf> user config file (I never touch my system-wide config), gnus features
 asf> are present).

	Yes, the built in Gnus is not suppressed.  Perhaps we should
 compare load paths? As you can see, 
   1) first in my load path come stuff under /home: no gnus there
   2) Next come directories in /usr/local/share/emacs/, and we do find
      Gnus there, in /usr/local/share/emacs/site-lisp/gnus-cvs/  <-- oort
   3) Next in line are directories under
      /usr/share/emacs21/site-lisp/, which  contain add-on packages
      separate from emacs (no Gnus here)
   4) Then come packages bundled with emacs (the Built in Gnus is
      present here, in /usr/share/emacs/21.2/lisp/gnus           <-- 5.9.0
   5) Finally, come the shared stand alone Gnus common source, (which
      is not compiled for emacs21) in
      /usr/share/emacs21/site-lisp/gnus                          <-- 5.8.8


	All my Gnus stuff comes from the second set of paths in my
 load path, namely /usr/local/share/emacs/site-lisp/gnus-cvs/ 

	This is the reason why we have debian-pkg-add-load-path-item.


	Hmm. If your path matches mine, then (clutching at straws), I have
 /etc/emacs20/site-start.d/20gnus-init.el, but no corresponding file
 in /etc/emacs21/site-start.d/20gnus-init.el. Do you have that? If so,
 that is the source of the problem (it should have been removed for
 you, though). 

	manoj

("/home/srivasta/lib/emacs/debian" 
 "/home/srivasta/lib/emacs/x-support" 
 "/home/srivasta/lib/emacs/modes" 
 "/home/srivasta/lib/emacs/mail" 
 "/home/srivasta/lib/emacs/lisp" 
 "/home/srivasta/lib/emacs/bbdb" 
 "/home/srivasta/lib/emacs/functions" 
 "/home/srivasta/lib/emacs/config" 
 "/home/srivasta/lib/emacs/emacs21" 
 "/home/srivasta/lib/emacs" 
 "/usr/local/share/emacs/21.2/site-lisp" 
 "/usr/local/share/emacs/site-lisp" 
 "/usr/local/share/emacs/site-lisp/auctex" 
 "/usr/local/share/emacs/site-lisp/bbdb-cvs" 
 "/usr/local/share/emacs/site-lisp/functions" 
 "/usr/local/share/emacs/site-lisp/gnus-cvs" 
 "/usr/local/share/emacs/site-lisp/mailcrypt-cvs" 
 "/usr/local/share/emacs/site-lisp/site-start.d" 
 "/usr/local/share/emacs/site-lisp/url-cvs" 
 "/usr/local/share/emacs/site-lisp/w3-cvs" 
 "/usr/local/share/emacs/site-lisp/bbdb-cvs/bits" 
 "/usr/local/share/emacs/site-lisp/bbdb-cvs/html" 
 "/usr/local/share/emacs/site-lisp/bbdb-cvs/lisp" 
 "/usr/local/share/emacs/site-lisp/bbdb-cvs/misc" 
 "/usr/local/share/emacs/site-lisp/bbdb-cvs/tex" 
 "/usr/local/share/emacs/site-lisp/bbdb-cvs/texinfo" 
 "/usr/local/share/emacs/site-lisp/bbdb-cvs/utils" 
 "/usr/local/share/emacs/site-lisp/gnus-cvs/contrib" 
 "/usr/local/share/emacs/site-lisp/gnus-cvs/debian" 
 "/usr/local/share/emacs/site-lisp/gnus-cvs/etc" 
 "/usr/local/share/emacs/site-lisp/gnus-cvs/lisp" 
 "/usr/local/share/emacs/site-lisp/gnus-cvs/texi" 
 "/usr/local/share/emacs/site-lisp/url-cvs/lisp" 
 "/usr/local/share/emacs/site-lisp/url-cvs/texi" 
 "/usr/local/share/emacs/site-lisp/w3-cvs/contrib" 
 "/usr/local/share/emacs/site-lisp/w3-cvs/etc" 
 "/usr/local/share/emacs/site-lisp/w3-cvs/lisp" 
 "/usr/local/share/emacs/site-lisp/w3-cvs/tests" 
 "/usr/local/share/emacs/site-lisp/w3-cvs/texi" 
 "/usr/local/share/emacs/site-lisp/bbdb-cvs/bits/bbdb-filters" 
 "/usr/local/share/emacs/site-lisp/bbdb-cvs/html/images" 
 "/usr/local/share/emacs/site-lisp/bbdb-cvs/html/patches" 
 "/usr/local/share/emacs/site-lisp/gnus-cvs/etc/gnus" 
 "/usr/local/share/emacs/site-lisp/gnus-cvs/etc/smilies" 
 "/usr/local/share/emacs/site-lisp/gnus-cvs/texi/etc" 
 "/usr/local/share/emacs/site-lisp/gnus-cvs/texi/herds" 
 "/usr/local/share/emacs/site-lisp/gnus-cvs/texi/misc" 
 "/usr/local/share/emacs/site-lisp/gnus-cvs/texi/picons" 
 "/usr/local/share/emacs/site-lisp/gnus-cvs/texi/ps" 
 "/usr/local/share/emacs/site-lisp/gnus-cvs/texi/screen" 
 "/usr/local/share/emacs/site-lisp/gnus-cvs/texi/smilies" 
 "/usr/local/share/emacs/site-lisp/gnus-cvs/texi/xface" 
 "/usr/local/share/emacs/site-lisp/w3-cvs/etc/w3" 
 "/usr/local/share/emacs/site-lisp/bbdb-cvs/bits/bbdb-filters/doc" 
 "/usr/local/share/emacs/site-lisp/w3-cvs/etc/w3/pixmaps" 
 "/usr/local/share/emacs/site-lisp/bbdb-cvs/bits/bbdb-filters/doc/formatted" 
 "/usr/share/emacs21/site-lisp/bitmap-mule" 
 "/usr/share/emacs21/site-lisp/xslide" 
 "/usr/share/emacs21/site-lisp/xae" 
 "/usr/share/emacs21/site-lisp/tramp" 
 "/usr/share/emacs21/site-lisp/speedbar" 
 "/usr/share/emacs21/site-lisp/psgml" 
 "/usr/share/emacs21/site-lisp/preview-latex" 
 "/usr/share/emacs21/site-lisp/pcl-cvs/" 
 "/usr/share/emacs21/site-lisp/lookup-el" 
 "/usr/share/emacs21/site-lisp/gnuserv" 
 "/usr/share/emacs21/site-lisp/gnus-bonus-el" 
 "/usr/share/emacs21/site-lisp/erc" 
 "/usr/share/emacs21/site-lisp/emacs-goodies-el" 
 "/usr/share/emacs21/site-lisp/eieio" 
 "/usr/share/emacs21/site-lisp/dpkg-dev-el" 
 "/usr/share/emacs21/site-lisp/debbugs-el" 
 "/usr/share/emacs/site-lisp/debbugs-el" 
 "/usr/share/emacs21/site-lisp/css-mode" 
 "/usr/share/emacs21/site-lisp/calc" 
 "/usr/share/emacs21/site-lisp/bbdb" 
 "/usr/local/share/emacs/site-lisp/auctex/" 
 "/usr/share/emacs21/site-lisp/mule-ucs" 
 "/usr/share/emacs21/site-lisp/elib/" 
 "/usr/share/emacs21/site-lisp/gnus" 
 "/usr/share/emacs21/site-lisp/apel" 
 "/etc/emacs21" 
 "/etc/emacs" 
 "/usr/share/emacs/21.2/site-lisp" 
 "/usr/share/emacs/site-lisp" 
 "/usr/share/emacs/21.2/leim" 
 "/usr/share/emacs/21.2/lisp" 
 "/usr/share/emacs/21.2/lisp/toolbar" 
 "/usr/share/emacs/21.2/lisp/textmodes" 
 "/usr/share/emacs/21.2/lisp/progmodes" 
 "/usr/share/emacs/21.2/lisp/play" 
 "/usr/share/emacs/21.2/lisp/obsolete" 
 "/usr/share/emacs/21.2/lisp/net" 
 "/usr/share/emacs/21.2/lisp/mail" 
 "/usr/share/emacs/21.2/lisp/language" 
 "/usr/share/emacs/21.2/lisp/international" 
 "/usr/share/emacs/21.2/lisp/gnus" 
 "/usr/share/emacs/21.2/lisp/eshell" 
 "/usr/share/emacs/21.2/lisp/emulation" 
 "/usr/share/emacs/21.2/lisp/emacs-lisp" 
 "/usr/share/emacs/21.2/lisp/calendar" 
 "/usr/share/emacs21/site-lisp/url" 
 "/usr/share/emacs21/site-lisp/ocaml" 
 "/usr/share/emacs21/site-lisp/sdic" 
 "/usr/share/emacs21/site-lisp/vm" 
 "/usr/share/emacs21/site-lisp/gnus" 
 "/usr/share/emacs21/site-lisp/w3-el" 
 "/usr/share/emacs21/site-lisp/whizzytex")


-- 
 American by birth; Texan by the grace of God.
Manoj Srivastava   <srivasta@acm.org>  <http://www.datasync.com/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Autoloads no longer working?

[Andreas Fuchs]

[-- Attachment #1: Type: text/plain, Size: 978 bytes --]

Today, Manoj Srivastava <srivasta@acm.org> wrote:
>  asf> I agree in that this problem is not a simple one; but I do think
>  asf> this is a debian issue (see my previous mail - when I suppress
>  asf> loading of the user config file (I never touch my system-wide
>  asf> config), gnus features are present).
> 
> 	Yes, the built in Gnus is not suppressed.  Perhaps we should
>  compare load paths? As you can see, 

I now know why this happens. And I could kick somebody for it. Most
probably, I will be the one who gets kicked (-:

The package w3-url-lisp's url.el has (require 'mailcap) in it. And guess
where mailcap.el(c) can be found? Right, in lisp/gnus/mailcap.el; This
one pulls in mm-util and all the others. I've just reported a bug on
this package, but I think this is a debian emacs bug, as well.

Oh well, so much for that problem (-:

Thanks for the help and patience from you all,
-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

[-- Attachment #2: Type: application/pgp-signature, Size: 231 bytes --]

Re: Autoloads no longer working?

[Kai Großjohann]

Andreas Fuchs <asf@void.at> writes:

> The package w3-url-lisp's url.el has (require 'mailcap) in it. And
> guess where mailcap.el(c) can be found? Right, in
> lisp/gnus/mailcap.el; This one pulls in mm-util and all the
> others. I've just reported a bug on this package, but I think this
> is a debian emacs bug, as well.

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.

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?

kai
-- 
Silence is foo!

Re: Autoloads no longer working?

[Andreas Fuchs]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

Today, Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> 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).

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

-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

[-- Attachment #2: Type: application/pgp-signature, Size: 231 bytes --]

Re: Autoloads no longer working?

[Kai Großjohann]

Andreas Fuchs <asf@void.at> writes:

> Today, Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> 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...


kai
-- 
Silence is foo!

Re: Autoloads no longer working?

[Andreas Fuchs]

[-- Attachment #1: Type: text/plain, Size: 774 bytes --]

Today, Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> wrote:
>> 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?

Well, the CVS version of url doesn't have it, either. And the w3 source
doesn't have it, either. I think it looks like this is a gnus only
thing. Where did you get your mailcap.el file from?

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

Ah, sorry, misparsed your text.

-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

[-- Attachment #2: Type: application/pgp-signature, Size: 231 bytes --]

Re: Autoloads no longer working?

[Harry Putnam]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Andreas Fuchs <asf@void.at> writes:
>
>> Today, Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> 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?

Re: Autoloads no longer working?

[Kai Großjohann]

Andreas Fuchs <asf@void.at> writes:

> Well, the CVS version of url doesn't have it, either. And the w3 source
> doesn't have it, either. I think it looks like this is a gnus only
> thing. Where did you get your mailcap.el file from?

I use the CVS version of url and w3 and of Gnus.  Now it turns out
that I also only have one mailcap.el, from Gnus.  (I didn't look
before.)

kai
-- 
Silence is foo!

Re: Autoloads no longer working?

[Andreas Fuchs]

[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]

On 2002-04-26, Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE>
wrote:
> Andreas Fuchs <asf@void.at> writes:
>> Well, the CVS version of url doesn't have it, either. And the w3
>> source doesn't have it, either. I think it looks like this is a gnus
>> only thing. Where did you get your mailcap.el file from?
> 
> I use the CVS version of url and w3 and of Gnus.  Now it turns out
> that I also only have one mailcap.el, from Gnus.  (I didn't look
> before.)

Yesterday, I poked deeper into my emacs's internals (with strace) and
noticed that url.el itself was (require)d by doxymacs's site-start
files. Removing the package from my system solved the error. I have
already reported this as a bug in doxymacs; 

After that adventure, I plan to write a load-path analyzer, something
that displays, in a tree format, which file gets loaded from where by
which other file (maybe even allowing for different faces in
require/autoload/loaded files).

Thanks for your help. Now for testing the spam features in gnus (-:

-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

[-- Attachment #2: Type: application/pgp-signature, Size: 231 bytes --]

Re: Autoloads no longer working?

[Paul Jarc]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote:
> 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?

Start emacs with --no-site-file, but *without* -q.  In .emacs, do
user-specific load-path frobbing and then load site-start.  This might
be thwarted if site-start adds load-path entries ahead of the user's
and then (require)s libraries from the site directories; that could be
worked around by (require)ing the libraries in .emacs before loading
site-start.  But it would be better if site-start added load-path
entries only when locate-library says that a library is not already
locatable.

Maybe there ought to be separate user-load-path and site-load-path
variables; user-load-path would always be consulted first, and
site-start would only modify site-load-path.


paul

Re: Autoloads no longer working?

[Kai Großjohann]

prj@po.cwru.edu (Paul Jarc) writes:

> But it would be better if site-start added load-path entries only
> when locate-library says that a library is not already locatable.

That might be a solution.

> Maybe there ought to be separate user-load-path and site-load-path
> variables; user-load-path would always be consulted first, and
> site-start would only modify site-load-path.

That might require a change in Emacs.  I think that Per will like it,
as it allows users to customize load-path, as well.  (Customize does
not work well with lists which are non-nil by default.  But
user-load-path would be nil by default, and so it would work well
with Customize.)

kai
-- 
Silence is foo!

Re: Autoloads no longer working?

[Paul Jarc]

I wrote:
> Maybe there ought to be separate user-load-path and site-load-path
> variables;

Of course, for backward compatibility, site-load-path should actually
be called load-path.


paul

Re: Autoloads no longer working?

[amos+lists.ding]

On Tue, 23 Apr 2002, Andreas Fuchs wrote:

> Actually, I noticed that these happen before the ~/.gnus gets loaded: I
> only get these messages:
>
> ,----
> | Loading gnus...
> | eval: Symbol's function definition is void: mm-guess-mime-charset
> `----

I just finished reading this thread after running into this too.
Though, I didn't see anything that might be applicable.

After using xemacs and gnus-0.05 (?) (CVS from not too long ago), I
decided to give latest emacs a try.  In fact I figured what the hell:
I'll try both latest emacs and gnus from CVS.  (I expect to be using
OS X on a TiBook before long and wanted the Aqua support checked into
emacs.)

Before going to xemacs I would add to the load path the directory for
my copy of gnus and the associated info files.  For years this worked
fine.  (With xemacs I just dumped all this stuff into
~/.xemacs/xemacs-packages and xemacs found everything on its own.  I
have to admit this has its advantages....)  So, I tried to restore my
old stuff so that I could go back to emacs.

First I ran into that error above.  Thinking it might be just that
specific library, I just did an explicit 'M-x load-library mm-util'.
That got me further.  Though, eventually I ran into:

 Symbol's function definition is void: gnus-update-alist-soft

Okay, since I don't expect anybody else to be using this particular
install of emacs, I just blew away lisp/gnus and info/gnus*.  I
figured I'd just pretend for now that emacs doesn't come with this.
Obviously not something I'd prefer to do, but I thought I'd give it a
try.  Well, when I do the 'make bootstrap' I now run into:

Compiling /usr/soft/that/emacs-21.2.cvs/src/default/sparc_sun_solaris2.8/lisp/obsolete/hilit19.el
/usr/soft/that/emacs-21.2.cvs/src/default/sparc_sun_solaris2.8/lisp/obsolete/hilit19.el: In toplevel form
/usr/soft/that/emacs-21.2.cvs/src/default/sparc_sun_solaris2.8/lisp/obsolete/hilit19.el: error: file error (("C
annot open load file" "gnus"))
make[1]: *** [compile] Error 1
make[1]: Leaving directory `/usr/soft/that/emacs-21.2.cvs/src/default/sparc_sun_solaris2.8/lisp'
make: *** [bootstrap-lisp] Error 2

Hmmm... I thought that was interesting, and perhaps overlooked.

Anyway, I guess I'll next dump the gnus from CVS into the directories
that emacs is expected to have.  Maybe that'll work better.  However,
I've got to run for now.

-Amos

Re: Autoloads no longer working?

[Amos Gouaux]

>>>>> On Tue, 30 Apr 2002 10:58:11 -0500 (CDT),
>>>>> lists ding <amos> (ld) writes:

ld> Anyway, I guess I'll next dump the gnus from CVS into the directories
ld> that emacs is expected to have.  Maybe that'll work better.  However,
ld> I've got to run for now.

Well, with some crude, impatient, brute force cramming I've got
things to work.  I have no idea how folks merge a new gnus release
into emacs, but what I did was replace lisp/gnus with the one from
gnus cvs.  I then copied etc/gnus/* into that directory (don't know
if they're needed or not).  I then had to remove lisp/gnus/gnus-xmas.el
because 'make bootstrap' would attempt to byte-compile that and it
would fail.

I can now startup gnus, but when I enter a group I get an error
about the undefined symbol 'copy-list'.  If I manually load dgnushack.el
then it works.  Maybe something missing or maybe in my haste I screwed
something up (probably).


-- 
Amos

Re: Autoloads no longer working?

[Amos Gouaux]

>>>>> On Tue, 30 Apr 2002 10:58:11 -0500 (CDT),
>>>>> lists ding <amos> (ld) writes:

ld> On Tue, 23 Apr 2002, Andreas Fuchs wrote:
>> Actually, I noticed that these happen before the ~/.gnus gets loaded: I
>> only get these messages:
>> 
>> ,----
>> | Loading gnus...
>> | eval: Symbol's function definition is void: mm-guess-mime-charset
>> `----

Surely I'm not the only one to run CVS Gnus with CVS Emacs, right?
Do y'all replace the gnus that's bundled with Emacs?  Then again, I
don't recall encountering this difficulty before.  Anyway, this
seems to allow me to fiddle with beta yet leave the bundled alone.
Maybe there's a better way to do this?  I'm concerned that I may
not be unloading everything I need to, or maybe unloading too
much.  Perhaps gnus-load.el should have an option to do an unload
of each feature it encounters while gnus-load.el is being built?

(add-to-list 'load-path 
             (expand-file-name "~/elisp/apps/gnus/lisp/"))

(add-to-list 'Info-default-directory-list
             (expand-file-name "~/elisp/apps/gnus/texi/"))

(dolist (feature features)
  (if (string-match "^\\(gnus-\\|nn\\|mm-\\|mml-\\|rfc\\|message\\)"
                    (symbol-name feature))
      (unload-feature feature 'force)))

(require 'gnus-load)

Hmm... this still isn't quite right.  When I tried to post I got:

Sending...
message-send-mail: Symbol's function definition is void: mml-buffer-substring-no-properties-except-hard-newlines

Maybe this will work after load-library of mml....

Re: Autoloads no longer working?

[Kai Großjohann]

Amos Gouaux <amos+lists.ding@utdallas.edu> writes:

> Surely I'm not the only one to run CVS Gnus with CVS Emacs, right?

I do that, and I just frob load-path pretty early on in the startup
process.

kai
-- 
Silence is foo!

Re: Autoloads no longer working?

[Amos Gouaux]

>>>>> On Sun, 05 May 2002 17:39:34 +0200,
>>>>> Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> (kg) writes:

kg> I do that, and I just frob load-path pretty early on in the startup
kg> process.

Sigh.  Yeah, that was it.  Didn't need that unload crap at all.
Just frob load-path and require 'gnus-load really early on.  Too
much old crap.  Moving what I was doing under XEmacs back to Emacs
also proved to be more tedious than I expected.

Sorry for the noise.

-Amos