From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.user/2781 Path: news.gmane.org!not-for-mail From: kai.grossjohann@gmx.net (=?iso-8859-1?q?Kai_Gro=DFjohann?=) Newsgroups: gmane.emacs.gnus.user Subject: Re: Trouble with nnir.el ("Invalid function ...") Date: Tue, 29 Jul 2003 16:13:54 +0200 Organization: University of Duisburg, Germany Message-ID: <84k7a1xvx9.fsf@slowfox.is.informatik.uni-duisburg.de> References: <84znj7q8u0.fsf@lucy.is.informatik.uni-duisburg.de> <87adaxbozu.fsf@phiwumbda.localnet> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1138669088 16331 80.91.229.2 (31 Jan 2006 00:58:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 31 Jan 2006 00:58:08 +0000 (UTC) Original-X-From: nobody Tue Jan 17 17:31:12 2006 Original-Path: quimby.gnus.org!newsfeed1.e.nsc.no!nsc.no!nextra.com!news.powertech.no!news.eunet.no!fu-berlin.de!uni-berlin.de!pd951f7f7.dip.t-dialin.NET!not-for-mail Original-Newsgroups: gnu.emacs.gnus Original-NNTP-Posting-Host: pd951f7f7.dip.t-dialin.net (217.81.247.247) Original-X-Trace: news.uni-berlin.de 1059488035 22149614 217.81.247.247 (16 [73968]) Mail-Copies-To: never User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:PPT5Vh74DqVuOeMv7Tj5nDpvgiU= Original-Xref: bridgekeeper.physik.uni-ulm.de gnus-emacs-gnus:2921 Original-Lines: 49 X-Gnus-Article-Number: 2921 Tue Jan 17 17:31:12 2006 Xref: news.gmane.org gmane.emacs.gnus.user:2781 Archived-At: jesseh@cs.kun.nl (Jesse F. Hughes) writes: >> | Debugger entered--Lisp error: (wrong-type-argument arrayp nil) >> | aset(nil 0 1) >> | (mail-header-set-number novitem idx) >> | (while (not (null artlist)) (setq art (car artlist)) (or (numberp art) (nnheader-report ... "nnir-retrieve-headers doesn't grok message ids: %s" art)) (setq artitem (nnir-artlist-article nnir-artlist art)) (setq artrsv (nnir-artitem-rsv artitem)) (setq artfullgroup (nnir-artitem-group artitem)) (setq artno (nnir-artitem-number artitem)) (setq artgroup (gnus-group-real-name artfullgroup)) (setq server (nnir-group-server artfullgroup)) (set-buffer nntp-server-buffer) (nnir-possibly-change-server server) (case (setq foo ...) (nov ... ... ...) (headers ... ... ...) (t ...)) (mail-header-set-number novitem idx) (mail-header-set-from novitem (mail-header-from novitem)) (mail-header-set-subject novitem (format "[%d: %s/%d] %s" artrsv artgroup artno ...)) (push novitem novdata) (setq artlist (cdr artlist)) (setq idx (1+ idx))) Really strange. Have a look at this code: (nnir-possibly-change-server server) (case (setq foo (gnus-retrieve-headers (list artno) artfullgroup nil)) (nov (goto-char (point-min)) (setq novitem (nnheader-parse-nov)) (unless novitem (pop-to-buffer nntp-server-buffer) (error "nnheader-parse-nov returned nil for article %s in group %s" artno artfullgroup))) (headers (goto-char (point-min)) (setq novitem (nnheader-parse-head)) (unless novitem (pop-to-buffer nntp-server-buffer) (error "nnheader-parse-head returned nil for article %s in group %s" artno artfullgroup))) (t (nnheader-report 'nnir "Don't support header type %s." foo))) ;; replace article number in original group with article number ;; in nnir group (mail-header-set-number novitem idx) I think the error is coming from there. Now, the case statement calls gnus-retrieve-headers and then looks at the result. If the result is nov, novitem is set and then checked for non-nil-ness. If the result is headers, then also novitem is set and then checked for non-nil-ness. And if the result was neither nov nor headers, then an error is generated. Thus, I expect that the last line from the above snippet is never reached for novitem being nil. What's wrong in this reasoning? Could you position point inside that function and do M-x edebug-defun RET and then use SPC to single-step through it to see what's happening? -- ~/.signature