nnoo bug

[Katsumi Yamaoka <yamaoka@jpl.org>]

Hi,

There's a mystery of long standing that the `nndraft-directory'
variable is sometimes set to the symbol `nndraft-directory'.  At
that time, the `nnmh-directory' variable is also set to the
symbol `nndraft-directory'.  It might happen to only people who
are interested in debugging and developing Gnus, though.  Now I
found out the way to reproduce it and the cause of the problem.

To reproduce the problem, enter the nndraft:drafts group[1],
load the nnmh library or the nndraft library, and exit the group.

The cause is that the `nnoo-declare' macro[2] adds the new entry
to the variables `nnoo-definition-alist' and `nnoo-state-alist'
whenever it is called.  When the nnmh module is re-loaded in the
nndraft:drafts group, the `nnoo-declare' macro registers the
nnmh back end in the `nnoo-state-alist' variable as
"*internal-non-initialized-backend*".  Because of this, the
`(nnmh-directory nndraft-directory)' element in the nndraft
entry which is registered in the `nnoo-definition-alist'
variable is processed by the `nnoo-change-server' function[3]
when exiting the nndraft:drafts group as:

  (set 'nnmh-directory 'nndraft-directory)

even though it should be:

  (set 'nnmh-directory (symbol-value 'nndraft-directory))

[1] It is required that there is at least one draft in the
nndraft:drafts group.
[2] All the nn* modules call the `nnoo-declare' macro at the top
level.
[3] The `nnoo-change-server' function is called by way of the
`gnus-close-server' function when exiting the nndraft group.

I've fixed the `nnoo-declare' macro so that it might never
generate duplicate entries.  BTW, does anyone know the reason to
use `eval-and-compile' there?  I left it.