Gnus development mailing list
 help / color / mirror / Atom feed
* Moving mail generates 'quit' signal
@ 2020-03-19  6:03 Bob Newell
  2020-03-19  7:03 ` Eric Abrahamsen
  2020-03-19 18:34 ` Bob Newell
  0 siblings, 2 replies; 3+ messages in thread
From: Bob Newell @ 2020-03-19  6:03 UTC (permalink / raw)
  To: ding

Aloha,

I've started to fetch mail from two secondary sources. One is
an IMAP server and all is well. The other is POP only and I've
run into an odd issue.

I have a function that I call after fetching to move mail from
the inbox of the secondary source to my gmail inbox, so
everything will be in the same place in the end. For the
secondary IMAP server this works but for the POP server, I get
a 'quit' condition, which I'm unable to completely trace thus
far.

Here's the operative code in question.

First the POP server setup, pretty standard.

  (add-to-list 'gnus-secondary-select-methods '(nnml "pop.netzero.com"))
  (setq mail-sources '((pop :server "pop.netzero.com"
                             :user "thatwouldbeme"
                             :password "highlysecret"
			     :port 110
			     )
			    ))

Now the move mail stuff. This is a little long but the quit
condition arises below in gnus-group-read-group, when I call
like this:

(rjn-do-mail-move "nnml+pop.netzero.com:mail.misc" "nnimap+imap.gmail.com:INBOX")

The quit condition is only when there is no mail to move. If
there is mail to move, it works fine. I've taken to
surrounding the line above like so:

(condition-case quit
    (rjn-do-mail-move "nnml+pop.netzero.com:mail.misc" "nnimap+imap.gmail.com:INBOX")
  (quit nil))
  )

This makes the problem go away but doesn't tell me why I have
it. Here's the rest of the code.

(defun rjn-do-mail-move (frombox tobox)
 "Move mail between mailboxes, even if between different IMAP
servers"
 (save-window-excursion
   ;; This selects the 'from' group if there is anything in it,
   ;; returning t.  If nothing in the group, return nil and do nothing
   ;; further. Note, we are not counting unread articles, we are
   ;; counting read AND unread, so gnus-group-unread won't work. We
   ;; move ALL articles, even old ones.

   ;; gnus-group-read-group seemingly returns t if there is
   ;; anything in the group and nil if not. But a quit
   ;; condition apparently arises if the 'frombox' is an nnml
   ;; group which is empty.
   
    (if (gnus-group-read-group 9999 t frombox)
       ;; We have articles (mail, maybe) to move.
       (progn
	 ;; Mark all articles with process mark.
	 (gnus-uu-mark-buffer)
	 ;; Move them in bulk to the 'to' group.
	 (gnus-summary-move-article nil tobox nil)
	 ;; Mark the 'from' group as caught up.
	 (gnus-summary-catchup t t)
         ;; Leave the 'from' group.
	 (gnus-summary-exit)
	 ;; Reset the group display to what it normally would be.
	 (gnus-group-list-groups)))))

I know this is weird and obscure but if anyone has an idea I'd
be most appreciative.

-- 
Bob Newell
Honolulu, Hawai`i
- Via Gnus/BBDB/Org/Emacs/Linux


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Moving mail generates 'quit' signal
  2020-03-19  6:03 Moving mail generates 'quit' signal Bob Newell
@ 2020-03-19  7:03 ` Eric Abrahamsen
  2020-03-19 18:34 ` Bob Newell
  1 sibling, 0 replies; 3+ messages in thread
From: Eric Abrahamsen @ 2020-03-19  7:03 UTC (permalink / raw)
  To: Bob Newell; +Cc: ding

Bob Newell <bobnewell@bobnewell.net> writes:

> Aloha,
>
> I've started to fetch mail from two secondary sources. One is
> an IMAP server and all is well. The other is POP only and I've
> run into an odd issue.
>
> I have a function that I call after fetching to move mail from
> the inbox of the secondary source to my gmail inbox, so
> everything will be in the same place in the end. For the
> secondary IMAP server this works but for the POP server, I get
> a 'quit' condition, which I'm unable to completely trace thus
> far.
>
> Here's the operative code in question.
>
> First the POP server setup, pretty standard.
>
>   (add-to-list 'gnus-secondary-select-methods '(nnml "pop.netzero.com"))
>   (setq mail-sources '((pop :server "pop.netzero.com"
>                              :user "thatwouldbeme"
>                              :password "highlysecret"
> 			     :port 110
> 			     )
> 			    ))
>
> Now the move mail stuff. This is a little long but the quit
> condition arises below in gnus-group-read-group

This will end up calling `gnus-summary-read-group', which calls
`gnus-summary-read-group-1', which up top calls `gnus-select-newsgroup',
and puts its return value into the let-bound variable `did-select'.

If `gnus-select-newsgroup' can't find any articles to read, it returns
the symbol `quit'. Then gnus-summary-read-group-1' sees that (in line
4037), and ends up signalling a quit error.

It's my bed time, but I'm guessing you should be using a function other
than `gnus-group-read-group'. All you want to be doing is checking the
group for new messages, right? This function is for interactively
entering the group, so the `quit' makes more sense in that situation.

If you haven't resolved this by morning my time, I can take another look
:)

Eric


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Moving mail generates 'quit' signal
  2020-03-19  6:03 Moving mail generates 'quit' signal Bob Newell
  2020-03-19  7:03 ` Eric Abrahamsen
@ 2020-03-19 18:34 ` Bob Newell
  1 sibling, 0 replies; 3+ messages in thread
From: Bob Newell @ 2020-03-19 18:34 UTC (permalink / raw)
  To: ding

Aloha again,

Following up on my question: I spent (too) much time in
edebug, and note that in the function gnus-select-newsgroup
(in gnus-sum.el) there is this snippet:

    (cond
     ((null articles)
      ;;(gnus-message 3 "Couldn't select newsgroup -- no articles to display")
      'quit)

This is where my quit condition is being generated.

It seems that the code above is intended to be applicable in
calls that (at least at the outer level) are interactive. My
call is non-interactive, and the quit condition results in a
total abort all the way back to the highest calling level.

Now we won't argue whether the way I've coded my move mail
function is the best (it certainly is far from it, and I'd
welcome ideas on improvement). The issue is, should a quit be
generated as above, making non-interactive use problematic (at
least as I read things)?

Mahalo

-- 
Bob Newell
Honolulu, Hawai`i
- Via Gnus/BBDB/Org/Emacs/Linux


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-03-19 18:35 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-19  6:03 Moving mail generates 'quit' signal Bob Newell
2020-03-19  7:03 ` Eric Abrahamsen
2020-03-19 18:34 ` Bob Newell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).