Unable to access nndraft:drafts in recent version of Gnus

Unable to access nndraft:drafts in recent version of Gnus

[Lloyd Zusman]

I've been using a three-or-four-week-old CVS release of Gnus 5.8.8,
and recently I decided to bring myself up to date with the latest CVS
release.  But once I installed it, all of the sudden, my
"nndraft:drafts" group ceased to work.

With the new CVS version, my "nndraft:drafts" group shows up with an
asterisk at its left and I cannot access it.  I cannot see any drafts
that go into that group.

However, if I revert back to my older Gnus 5.8.8, my "nndraft:drafts"
group works again.  Also, if I use the latest CVS version to create
drafts, I can then exit Gnus and restart the three-or-four-week-old
version, and I then see my drafts in "nndraft:drafts".  But if I don't
exit the newest version, the drafts I create don't appear and the
"nndraft:drafts" group remains inaccessible with the asterisk next to
it.

I didn't change anything at all about my configuration.  The only
change I make is to switch between the newest CVS version and my
three-to-four-week-old version.

The only drafts-related variable that I have set within my `gnus.el'
file is ...

  (setq nndraft-directory "~/News/drafts/")
 
... and this variable has been set literally for years and has caused
no problems for me during that time.

Any ideas?

Thanks in advance.

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: Unable to access nndraft:drafts in recent version of Gnus

[Matthias Wiehl]

Lloyd Zusman <ljz@asfast.com> writes:

> With the new CVS version, my "nndraft:drafts" group shows up with an
> asterisk at its left and I cannot access it.  I cannot see any drafts
> that go into that group.

You will have to byte-compile Gnus in order to make your drafts group
work properly again.  Lars Magne Ingebrigtsen writes:

,----[ <m3r97xhrp6.fsf@quimbies.gnus.org> ]
| Gnus has a pretty deep Lisp eval depth (lots of macros that create
| lexical environments (ahem)), and when running Gnus uncompiled, the
| default Emacs max-lisp-eval-depth is exceeded, which makes Gnus bug
| out.  However, there's an ignore-error around the group activation
| calls, which makes Gnus ignore the bugout, leading Gnus just to ignore
| those groups.
`----

Re: Unable to access nndraft:drafts in recent version of Gnus

[Lloyd Zusman]

Matthias Wiehl <mwiehl@gmx.de> writes:

> Lloyd Zusman <ljz@asfast.com> writes:
> 
> > With the new CVS version, my "nndraft:drafts" group shows up with an
> > asterisk at its left and I cannot access it.  I cannot see any drafts
> > that go into that group.
> 
> You will have to byte-compile Gnus in order to make your drafts group
> work properly again.  Lars Magne Ingebrigtsen writes:
>
> [ ... ]

I found Lars' comments in my gnus mailing list archives before posting
my question to this group.  However, I always byte-compile everything,
and in the case of this problem, my gnus was also byte-compiled
properly.

It turns out that the problem has something to do with changing my
`load-path' to contain an entry that points to a newly downloaded
(from cvs) version of gnus that has indeed been byte-compiled, instead
of using the original `load-path' entry which points to the directory
path for the gnus version I had previously been using.  It appears
that now there is something in my normal `load-path' that gnus needs,
and when the version pointed to by the altered `load-path' is run,
this `nndrafts:drafts' problem occurs.  If I install the latest
version into my normal load path, the problem goes away.

I have been using this same method of switching `load-path' entries to
test downloads of gnus for the better part of a year, and this
`nndrafts:drafts' problem hadn't occurred at all until recently.

Once I stumbled upon this connection to `load-path', however, I
stopped looking for the real cause of the problem, since it only seems
to occur when testing.

Thanks for your suggestion, however.

Any ideas about how a `load-path' change could affect the ability for
gnus to recognize the `nndrafts:drafts' folder? ... especially given
that the only path component I change is the one which points to gnus
directory tree, which contains nothing at all but the byte-compiled
gnus release ... ???

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: Unable to access nndraft:drafts in recent version of Gnus

[Kai Großjohann]

On 01 Oct 2000, Lloyd Zusman wrote:

> Any ideas about how a `load-path' change could affect the ability
> for gnus to recognize the `nndrafts:drafts' folder? ... especially
> given that the only path component I change is the one which points
> to gnus directory tree, which contains nothing at all but the
> byte-compiled gnus release ... ???

How exactly did you change your load-path?  I always install the new
version of Gnus in some directory, then (add-to-list 'load-path
"/some/directory/"), and this works nicely.  I don't replace the
normal Gnus load-path entry, though, I just tack on a new one in front
of load-path.

kai
-- 
I like BOTH kinds of music.

Re: Unable to access nndraft:drafts in recent version of Gnus

[Lloyd Zusman]

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

> On 01 Oct 2000, Lloyd Zusman wrote:
> 
> > Any ideas about how a `load-path' change could affect the ability
> > for gnus to recognize the `nndrafts:drafts' folder? ... especially
> > given that the only path component I change is the one which points
> > to gnus directory tree, which contains nothing at all but the
> > byte-compiled gnus release ... ???
> 
> How exactly did you change your load-path?  I always install the new
> version of Gnus in some directory, then (add-to-list 'load-path
> "/some/directory/"), and this works nicely.  I don't replace the
> normal Gnus load-path entry, though, I just tack on a new one in front
> of load-path.

I do it just like you do.  I just conditionally use either
"/some/directory1" or "/some/directory2", depending on whether I want
the newest or older version.

And remember, this worked just fine for around a year, and only with
recent CVS downloads did I start having the problem I was reporting.

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: Unable to access nndraft:drafts in recent version of Gnus

[Kai Großjohann]

On 02 Oct 2000, Lloyd Zusman wrote:

> And remember, this worked just fine for around a year, and only with
> recent CVS downloads did I start having the problem I was reporting.

Strange.  Still works fine for me.  Most recent lisp/ChangeLog entry:

2000-08-05  Simon Josefsson <simon@josefsson.org>

        Make GCC to remote groups work when unplugged
        (postpone GCC until message is actually sent).

kai
-- 
I like BOTH kinds of music.

Solved! (Was: Unable to access nndraft:drafts in recent version of Gnus)

[Lloyd Zusman]

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

> On 02 Oct 2000, Lloyd Zusman wrote:
> 
> > And remember, this worked just fine for around a year, and only with
> > recent CVS downloads did I start having the problem I was reporting.
> 
> Strange.  Still works fine for me.  Most recent lisp/ChangeLog entry:

Problem solved!

It turns out that the file permissions of the *.elc files were getting
set wrong for the version of gnus that I download from CVS and then
test.  I do this as a different user ID than the one that gnus
normally runs under, and the umask caused the *.elc files to be
unreadable by the other user ID where I run gnus.

I fixed the script in which I wrap my cvs download and build steps,
and now everything works fine.

As it turns out, the suggestion of a few days ago about no byte
compilation actually was pointing to the cause of my problem, after
all.

Thanks to all of you who took the time to try to help me solve this
mystery.

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: Unable to access nndraft:drafts in recent version of Gnus

[Jari Aalto+mail.emacs]

* 2000-10-01 Matthias Wiehl <mwiehl@gmx.de> list.emacs-ding
* Message-Id: <87g0mgwy9h.fsf@fulmine.dhs.org>
| Lloyd Zusman <ljz@asfast.com> writes:
| 
| > With the new CVS version, my "nndraft:drafts" group shows up with an
| > asterisk at its left and I cannot access it.  I cannot see any drafts
| > that go into that group.
| 
| You will have to byte-compile Gnus in order to make your drafts group
| work properly again.  Lars Magne Ingebrigtsen writes:
| 
| ,----[ <m3r97xhrp6.fsf@quimbies.gnus.org> ]
| | Gnus has a pretty deep Lisp eval depth (lots of macros that create
| | lexical environments (ahem)), and when running Gnus uncompiled, the
| | default Emacs max-lisp-eval-depth is exceeded, which makes Gnus bug
| | out.  However, there's an ignore-error around the group activation
| | calls, which makes Gnus ignore the bugout, leading Gnus just to ignore
| | those groups.

This is unfortunate, it should at least pause and give a message,
not just ignore the errors.

The compiled versions are not usually good for developers, because you
can't get a decent backtrace and understand what went wrong. Then there
is issue of running the same code with XEmacs and Emacs, which requires
non-compiled versions.

In case anyone is interested here is what I currently use for
non-compiled gnus. I think Gnus should autocheck if the 
'nndraft-request-group is ok, (it is set to 'ignore in case of
error) so that users wouldn't need the code below.

Jari


(defadvice gnus-topic-read-group (before my-gnus-fix-nndraft act)
  "Fix broken nndraft."
  (when (eq 'ignore (symbol-function 'nndraft-request-group))
    (my-gnus-nndraft-fix)))

(defun my-gnus-nndraft-fix  ()
  "Bug in my gnus that prevent accessing nndraft.
Define function `nndaft-request-group'."
  (interactive)
  (let* ((function          'nndraft-request-group)
         (call-function     'nnoo-parent-function)
         (backend           'nndraft)
         (this-function     'nnmh-request-group)
         )

    ;; nndraft.el
    ;; (defvoo nndraft-directory (nnheader-concat gnus-directory "drafts/"))

    (unless (stringp nndraft-directory)
      (setq nndraft-directory (nnheader-concat gnus-directory "drafts/")))

    (eval `(deffoo ,function (&rest args)
             (,call-function ',backend ',this-function args)))
    ))