When attempting to send messages from my queue which I composed while unplugged, emacs complains that nnimap-request-restore-buffer is an undefined symbol. To send these messages I had to hack a dummy function into place, but of course it stopped after each message complaining that the buffer couldn't be restored. Am I doing something wrong? Maybe when using GNUs from CVS I need to also be using emacs from CVS? Can someone give me guidance on which branch of emacs to check out for GNUs o0-15? Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes: > When attempting to send messages from my queue which I composed while > unplugged, emacs complains that nnimap-request-restore-buffer is an > undefined symbol. To send these messages I had to hack a dummy > function into place, but of course it stopped after each message > complaining that the buffer couldn't be restored. Am I doing > something wrong? No. Can you get post the backtrace? It looks like a bug. > Maybe when using GNUs from CVS I need to also be using emacs from CVS? Nope. > Can someone give me guidance on which branch of emacs to check out > for GNUs o0-15? Anyone will do, I suggest HEAD.
Simon Josefsson <jas@extundo.com> writes: > David Abrahams <dave@boost-consulting.com> writes: > >> When attempting to send messages from my queue which I composed while >> unplugged, emacs complains that nnimap-request-restore-buffer is an >> undefined symbol. To send these messages I had to hack a dummy >> function into place, but of course it stopped after each message >> complaining that the buffer couldn't be restored. Am I doing >> something wrong? > > No. Can you get post the backtrace? It looks like a bug. Sorry, I don't have it. I'll try to generate them in the future when things like this come up, though. >> Maybe when using GNUs from CVS I need to also be using emacs from CVS? > > Nope. Well, certainly the released version (21.2.1) does NOT work. GNUs passes some extra args to functions whose signatures have changed. >> Can someone give me guidance on which branch of emacs to check out >> for GNUs o0-15? > > Anyone will do, I suggest HEAD. I'll try rebuilding from source now. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
>>> Maybe when using GNUs from CVS I need to also be using emacs from CVS?
>>
>> Nope.
>
> Well, certainly the released version (21.2.1) does NOT work. GNUs
> passes some extra args to functions whose signatures have changed.
Can you be more specific? Oort is supposed to work on Emacs >= 20.3
and XEmacs >= 20.4.
[-- Attachment #1: Type: text/plain, Size: 577 bytes --] Simon Josefsson <jas@extundo.com> writes: > David Abrahams <dave@boost-consulting.com> writes: > >>>> Maybe when using GNUs from CVS I need to also be using emacs from CVS? >>> >>> Nope. >> >> Well, certainly the released version (21.2.1) does NOT work. GNUs >> passes some extra args to functions whose signatures have changed. > > Can you be more specific? Oort is supposed to work on Emacs >= 20.3 > and XEmacs >= 20.4. The following thread details all I can remember (I don't remember where the call originated, but I think it was message mail abbrev expansion). --- [-- Attachment #2.1: Type: text/plain, Size: 100 bytes --] Subject: Topics Topics: mailabbrev.el bug? Re: mailabbrev.el bug? Re: mailabbrev.el bug? [-- Attachment #2.2: Type: text/plain, Size: 1216 bytes --] Date: Sat, 08 Feb 2003 22:13:46 -0500 From: David Abrahams <dave@boost-consulting.com> Subject: mailabbrev.el bug? Message-ID: <ur8aijgd1.fsf@boost-consulting.com> MIME-Version: 1.0 Unless define-abbrev has changed its signature since 21.2.1, I found a bug in mailabbrev.el, which I fixed with this patch: *** mailabbrev.el.~1.71.~ Sun Jan 12 15:48:49 2003 --- mailabbrev.el Sat Feb 8 21:39:43 2003 *************** *** 315,321 **** (setq name (downcase name)) ;; use an abbrev table instead of an alist for mail-abbrevs. (let ((abbrevs-changed abbrevs-changed)) ; protect this from being changed. ! (define-abbrev mail-abbrevs name definition 'mail-abbrev-expand-hook 0 t))) (defun mail-resolve-all-aliases () --- 315,322 ---- (setq name (downcase name)) ;; use an abbrev table instead of an alist for mail-abbrevs. (let ((abbrevs-changed abbrevs-changed)) ; protect this from being changed. ! (define-abbrev mail-abbrevs name definition 'mail-abbrev-expand-hook 0 ;t ;; dwa -- this seems to be an extra argument that isn't recognized by define-abbrev ! ))) (defun mail-resolve-all-aliases () -- Dave Abrahams Boost Consulting www.boost-consulting.com [-- Attachment #2.3: Type: text/plain, Size: 465 bytes --] Date: Mon, 10 Feb 2003 05:35:07 -0500 From: Richard Stallman <rms@gnu.org> Cc: emacs-devel@gnu.org Subject: Re: mailabbrev.el bug? Message-ID: <E18iBHH-0004bm-00@fencepost.gnu.org> References: <ur8aijgd1.fsf@boost-consulting.com> MIME-Version: 1.0 ! (define-abbrev mail-abbrevs name definition 'mail-abbrev-expand-hook 0 t))) That looks correct to me. define-abbrev takes 6 args and this seems to pass them all correctly. Why do you think it is wrong? [-- Attachment #2.4: Type: text/plain, Size: 846 bytes --] Date: Mon, 10 Feb 2003 07:13:13 -0500 From: David Abrahams <dave@boost-consulting.com> Cc: emacs-devel@gnu.org Subject: Re: mailabbrev.el bug? Message-ID: <uznp4jpuu.fsf@boost-consulting.com> References: <ur8aijgd1.fsf@boost-consulting.com> <E18iBHH-0004bm-00@fencepost.gnu.org> MIME-Version: 1.0 Richard Stallman <rms@gnu.org> writes: > ! (define-abbrev mail-abbrevs name definition 'mail-abbrev-expand-hook 0 t))) > > That looks correct to me. define-abbrev takes 6 args and this seems > to pass them all correctly. Why do you think it is wrong? Anly because it gave me an error when I replaced my 21.2.1 elisp/mail folder with the CVS... I realize it's undisciplined, but you know how GNUs users are; we always want something that's not supported in the release ;-). -- Dave Abrahams Boost Consulting www.boost-consulting.com [-- Attachment #3: Type: text/plain, Size: 61 bytes --] -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes: >> David Abrahams <dave@boost-consulting.com> writes: >> >>> When attempting to send messages from my queue which I composed while >>> unplugged, emacs complains that nnimap-request-restore-buffer is an >>> undefined symbol. To send these messages I had to hack a dummy >>> function into place, but of course it stopped after each message >>> complaining that the buffer couldn't be restored. Am I doing >>> something wrong? I tried to reproduce this, but was not able to. > Well, certainly the released version (21.2.1) does NOT work. GNUs > passes some extra args to functions whose signatures have changed. I'm using "GNU Emacs 21.2.1 (i386-mingw-nt5.0.2195) of 2002-03-26 on PCNIKLAS2", gnus CVS and nnimap. FWIW I have never seen the problem you are describing. However, trying to eval this (as you described in <uvfzesa8p.fsf@boost-consulting.com>) from your updated mailabbrev.el: (define-abbrev mail-abbrevs name definition 'mail-abbrev-expand-hook 0 t) gives me an error as well. But mailabbrev isn't part of gnus, it's part of emacs. If you upgrade only some parts of emacs to CVS and not the rest it is not surprising that it doesn't work. In the mailabbrev.el that comes with emacs 21.2.1 the call is: (define-abbrev mail-abbrevs name definition 'mail-abbrev-expand-hook))) which works fine. Niklas
David Abrahams <dave@boost-consulting.com> writes: > Simon Josefsson <jas@extundo.com> writes: > >> David Abrahams <dave@boost-consulting.com> writes: >> >>>>> Maybe when using GNUs from CVS I need to also be using emacs from CVS? >>>> >>>> Nope. >>> >>> Well, certainly the released version (21.2.1) does NOT work. GNUs >>> passes some extra args to functions whose signatures have changed. >> >> Can you be more specific? Oort is supposed to work on Emacs >= 20.3 >> and XEmacs >= 20.4. > > The following thread details all I can remember (I don't remember > where the call originated, but I think it was message mail abbrev > expansion). ... > Anly because it gave me an error when I replaced my 21.2.1 elisp/mail > folder with the CVS... I realize it's undisciplined, but you know how > GNUs users are; we always want something that's not supported in the > release ;-). I think this explains it. Using elisp from Emacs version X+1 in Emacs version X doesn't work reliably. Even elisp written for Emacs X but byte compiled with Emacs X+1 doesn't work on Emacs version X reliably. I tried starting my Oort on Emacs 20 and it seems to work fine here. But if you get an error, a backtrace would help tracking down any bug.
Simon Josefsson <jas@extundo.com> writes:
> David Abrahams <dave@boost-consulting.com> writes:
>> When attempting to send messages from my queue which I composed while
>> unplugged, emacs complains that nnimap-request-restore-buffer is an
>> undefined symbol. To send these messages I had to hack a dummy
>> function into place, but of course it stopped after each message
>> complaining that the buffer couldn't be restored. Am I doing
>> something wrong?
>
> No. Can you get post the backtrace? It looks like a bug.
Errr, I ran across this once, when an injudicious edit of my
groups.eld mangled the definition for nndrafts. In other words, it
wasn't really nnimap related at all.
Hope this helps.
Mike.
Niklas Morberg <niklas.morberg@axis.com> writes:
>> Well, certainly the released version (21.2.1) does NOT work. GNUs
>> passes some extra args to functions whose signatures have changed.
>
> I'm using "GNU Emacs 21.2.1 (i386-mingw-nt5.0.2195) of
> 2002-03-26 on PCNIKLAS2", gnus CVS and nnimap. FWIW I have
> never seen the problem you are describing.
>
> However, trying to eval this (as you described in
> <uvfzesa8p.fsf@boost-consulting.com>) from your
> updated mailabbrev.el:
Sorry, it's more-complicated than I said. In order to get nnimap
with SSL working I was advised to "get a newer xxxx.el" for several
definitions of xxxx, so that's where this whole thing started. I'm
now working with the HEAD of emacs CVS and oO-15, with few problems.
Thanks,
Dave
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com