Releasing the new nnimap on y'all soon

Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

I'll be releasing the new nnimap later tonight, so be prepared for some
breakage.  :-)

Katsumi, this should probably not be pushed to the Emacs trunk until all
the (presumed) problems have been ironed out.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I'll be releasing the new nnimap later tonight, so be prepared for some
> breakage.  :-)

I pushed it out now.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Dan Christensen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> I'll be releasing the new nnimap later tonight, so be prepared for some
>> breakage.  :-)
>
> I pushed it out now.

Should it be mostly a drop-in replacement?  For example, there are two
IMAP servers I currently access, one using a shell connection and the
other using a network connection:

      (setq imap-shell-program '("ssh %s dovecot --exec-mail imap"))
      (add-to-list 'gnus-secondary-select-methods
		   '(nnimap "jdc"
			    (nnimap-address "remote.imap.server")
			    ;(nnimap-server-port XXXXX)
			    ;(nnimap-authenticator login)
			    (nnimap-stream shell)
			    ))
      (add-to-list 'gnus-secondary-select-methods
		   '(nnimap "rocky"
			    (nnimap-address "localhost")
			    (nnimap-server-port 143)
			    ;(nnimap-authenticator login)
			    (nnimap-stream network)
			    ; Summary generation is faster with this t:
			    (nnimap-nov-is-evil t)
			    ))

Will these sorts of settings still be honoured?  Using the shell
connection has been more reliable for me, as it seems to work-around
oddities in my university's intrusion detection system.

Dan

Re: Releasing the new nnimap on y'all soon

[Knut Anders Hatlen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> I'll be releasing the new nnimap later tonight, so be prepared for some
>> breakage.  :-)
>
> I pushed it out now.

Great! I gave it a go. My first impressions:

I had one server that used nnimap-stream shell, and it stopped working
since we now only support imap and ssl streams now. Any plans of adding
shell streams back?

My other nnimap server talked to imap.gmail.com over an ssl stream, but
it failed to connect because there was no imaps entry in /etc/services
(this was on Solaris). Added an entry, and killed the two attempts to
connect using gnutls-cli (they hung, don't know why, as the commands
seem to work from a terminal) so that it fell back to using openssl
s_client, and then I got in.

Haven't got around to testing much yet. The one thing I have noticed is
that the summary buffer displays question marks instead of the number of
lines in the messages.

-- 
Knut Anders

Re: Releasing the new nnimap on y'all soon

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Katsumi, this should probably not be pushed to the Emacs trunk until
> all the (presumed) problems have been ironed out.

I assume you need, like, guinea pigs...?

Re: Releasing the new nnimap on y'all soon

[Steinar Bang]

>>>>> Steinar Bang <sb@dod.no>:

> I assume you need, like, guinea pigs...?

Stopped with the following message in the minibuffer:
 nnimap-request-list: Symbol's function definition is void: utf7-encode

This is in GNU Emacs 22.2.1 on Ubuntu 10.04 "Lucid Lynx" UNE (Ubuntu
Netbook Edition).  The reason for using emacs22 instead of the default
emacs23, is that emacs23 doesn't work under the UNE window manager.

The full trace in the *Messages* buffer is:

Initializing the sync facility
Loading gnus-demon...done
Loading gnus-agent...done
Loading auth-source...done
Loading bbdb-gnus...done
Reading /home/sb/.newsrc.eld...
gnus-sync: loading from backend /ssh:sb@hjemme.mydomain.no:News/gnussync
Loading tramp...done
tramp: Opening connection for sb@hjemme.mydomain.no using ssh...
tramp: Waiting for prompts from remote shell
tramp: Waiting 60s for prompt from remote shell
tramp: Found remote shell prompt.
tramp: Initializing remote shell
tramp: Waiting 30s for remote `/bin/sh' to come up...
tramp: Setting up remote shell environment
tramp: Checking remote host type for `send-process-string' bug
tramp: Determining coding system
tramp: Waiting 30s for `HISTFILE=$HOME/.tramp_history; HISTSIZE=1; export HISTFILE; export HISTSIZE'
tramp: Waiting 30s for `set +o vi +o emacs'
tramp: Waiting 30s for `unset MAIL MAILCHECK MAILPATH'
tramp: Waiting 30s for `unset CDPATH'
tramp: Setting shell prompt
tramp: Remote `/bin/sh' groks tilde expansion, good
tramp: Finding command to check if file exists
tramp: Finding a suitable `ls' command
tramp: Checking remote `/usr/xpg4/bin/ls' command for `-n' option
tramp: Checking remote `/bin/ls' command for `-n' option
tramp: Testing remote command `/bin/ls' for -n...okay
tramp: Using remote command `/bin/ls' for getting directory listings
tramp: Sending the Perl `mime-encode' implementations.
tramp: Sending the Perl `mime-decode' implementations.
tramp: Checking remote encoding command `mimencode -b' for sanity
tramp: Checking remote encoding command `mmencode -b' for sanity
tramp: Checking remote encoding command `recode data..base64' for sanity
tramp: Checking remote encoding command `uuencode xxx' for sanity [4 times]
tramp: Checking remote encoding command `tramp_encode_with_module' for sanity
tramp: Checking remote decoding command `tramp_decode_with_module' for sanity
tramp: Checking to see if encoding/decoding commands work on remote host...done
tramp: Encoding remote file /ssh:sb@hjemme.mydomain.no:/home/sb/News/gnussync...
tramp: Decoding remote file /ssh:sb@hjemme.mydomain.no:/home/sb/News/gnussync...
tramp: Decoding remote file /ssh:sb@hjemme.mydomain.no:/home/sb/News/gnussync with function base64-decode-region...
Wrote /tmp/tramp.32214PrQ
tramp: Decoding remote file /ssh:sb@hjemme.mydomain.no:/home/sb/News/gnussync...done
tramp: Sending the Perl script `tramp_file_attributes'...done.
gnus-sync: loaded 118 groups (out of 118) from /ssh:sb@hjemme.mydomain.no:News/gnussync
Reading active file from news via nntp...
Reading active file from privat via nnimap...
Opening nnimap server on privat...
Loading tls...done
Opening TLS connection to `imap.mydomain.no'...
Opening TLS connection with `gnutls-cli -p imaps imap.mydomain.no'...failed
Opening TLS connection with `gnutls-cli -p imaps imap.mydomain.no --protocols ssl3'...failed
Opening TLS connection with `openssl s_client -connect imap.mydomain.no:imaps -no_ssl2 -ign_eof'...done
Opening TLS connection to `imap.mydomain.no'...done
Opening nnimap server on privat...failed
nnimap-request-list: Symbol's function definition is void: utf7-encode

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Dan Christensen <jdc@uwo.ca> writes:

> Should it be mostly a drop-in replacement?  For example, there are two
> IMAP servers I currently access, one using a shell connection and the
> other using a network connection:
>
>       (setq imap-shell-program '("ssh %s dovecot --exec-mail imap"))

This one is not supported.

>       (add-to-list 'gnus-secondary-select-methods
> 		   '(nnimap "jdc"
> 			    (nnimap-address "remote.imap.server")
> 			    ;(nnimap-server-port XXXXX)
> 			    ;(nnimap-authenticator login)
> 			    (nnimap-stream shell)

Ah, I've forgotten to implement the shell thing for nnimap-stream, so
that won't work.  I'll get to it.

The rest should work OK, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

>> I assume you need, like, guinea pigs...?

Yes.  :-)

> Stopped with the following message in the minibuffer:
>  nnimap-request-list: Symbol's function definition is void: utf7-encode

Do you have

(load "gnus-load")

in your .gnus.el file?  That's necessary to get the Gnus autoloads
working for the development version.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Knut Anders Hatlen]

[-- Attachment #1: Type: text/plain, Size: 1764 bytes --]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>
>>> I'll be releasing the new nnimap later tonight, so be prepared for some
>>> breakage.  :-)
>>
>> I pushed it out now.
>
> Great! I gave it a go. My first impressions:
>
> I had one server that used nnimap-stream shell, and it stopped working
> since we now only support imap and ssl streams now. Any plans of adding
> shell streams back?
>
> My other nnimap server talked to imap.gmail.com over an ssl stream, but
> it failed to connect because there was no imaps entry in /etc/services
> (this was on Solaris). Added an entry, and killed the two attempts to
> connect using gnutls-cli (they hung, don't know why, as the commands
> seem to work from a terminal) so that it fell back to using openssl
> s_client, and then I got in.
>
> Haven't got around to testing much yet. The one thing I have noticed is
> that the summary buffer displays question marks instead of the number of
> lines in the messages.

And a third configuration I have, talking to an IMAP server that doesn't
identify itself (I *think* it's Zimbra) fails in nnimap-get-groups
because the second argument in (string-match "noselect" (caadr line)) is
nil.

This happens because the LIST response from the server doesn't have any
name attributes. Example:

7 LIST "" "*"^M
* LIST () "/" "apache.db-pmc"
* LIST () "/" "apache.derby-commits"
* LIST () "/" "apache.derby-dev"
(...)
* LIST () "/" "Trash"
7 OK LIST completed

Simple fix that makes it skip looking for the noselect attribute if
there are no attributes is attached.

More to come, hopefully, since I still cannot actually see any messages
in the groups...

-- 
Knut Anders

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: nil.diff --]
[-- Type: text/x-patch, Size: 503 bytes --]

diff --git a/lisp/nnimap.el b/lisp/nnimap.el
index 548b6ec..3caa58e 100644
--- a/lisp/nnimap.el
+++ b/lisp/nnimap.el
@@ -416,7 +416,8 @@ not done by default on servers that doesn't support that command.")
     (when (car result)
       (dolist (line (cdr result))
 	(when (and (equal (car line) "LIST")
-		   (not (string-match "noselect" (caadr line))))
+		   (not (and (caadr line)
+			     (string-match "noselect" (caadr line)))))
 	  (push (car (last line)) groups)))
       (nreverse groups))))
 

Re: Releasing the new nnimap on y'all soon

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Do you have

> (load "gnus-load")

> in your .gnus.el file?  That's necessary to get the Gnus autoloads
> working for the development version.

Now I do.  It got me a little further.

Short summary:

 - It says "opening nntp server blah failed" for all of my nntp servers,
   even though it seems to (at least partly) work.  The one that
   actually fails ie. news.eclipse.org, fails on old gnus
 - It says failed on the nnimap server as well, but it comes up with the
   correct new article count, but it fails when trying to enter the
   group on the server that has the new articles:
    - It uses a lot of time to read a small amount of data
    - It fails with the following message in the minibuffer:
	mapc: Wrong type argument: char-or-string-p, (nil nil)

Here's the *Messages* trace:

Loading browse-url...done
Initializing the sync facility
Loading /home/sb/git/gnus/lisp/gnus-load.el (source)...done
Loading gnus-demon...done
Loading gnus-agent...done
Loading auth-source...done
Loading bbdb-gnus...done
Reading /home/sb/.newsrc.eld...
gnus-sync: loading from backend /ssh:sb@hjemme.mydomain.no:News/gnussync
Loading tramp...done
tramp: Opening connection for sb@hjemme.mydomain.no using ssh...
tramp: Waiting for prompts from remote shell
tramp: Waiting 60s for prompt from remote shell
tramp: Found remote shell prompt.
tramp: Initializing remote shell
tramp: Waiting 30s for remote `/bin/sh' to come up...
tramp: Setting up remote shell environment
tramp: Checking remote host type for `send-process-string' bug
tramp: Determining coding system
tramp: Waiting 30s for `HISTFILE=$HOME/.tramp_history; HISTSIZE=1; export HISTFILE; export HISTSIZE'
tramp: Waiting 30s for `set +o vi +o emacs'
tramp: Waiting 30s for `unset MAIL MAILCHECK MAILPATH'
tramp: Waiting 30s for `unset CDPATH'
tramp: Setting shell prompt
tramp: Remote `/bin/sh' groks tilde expansion, good
tramp: Finding command to check if file exists
tramp: Finding a suitable `ls' command
tramp: Checking remote `/usr/xpg4/bin/ls' command for `-n' option
tramp: Checking remote `/bin/ls' command for `-n' option
tramp: Testing remote command `/bin/ls' for -n...okay
tramp: Using remote command `/bin/ls' for getting directory listings
tramp: Sending the Perl `mime-encode' implementations.
tramp: Sending the Perl `mime-decode' implementations.
tramp: Checking remote encoding command `mimencode -b' for sanity
tramp: Checking remote encoding command `mmencode -b' for sanity
tramp: Checking remote encoding command `recode data..base64' for sanity
tramp: Checking remote encoding command `uuencode xxx' for sanity [4 times]
tramp: Checking remote encoding command `tramp_encode_with_module' for sanity
tramp: Checking remote decoding command `tramp_decode_with_module' for sanity
tramp: Checking to see if encoding/decoding commands work on remote host...done
tramp: Encoding remote file /ssh:sb@hjemme.mydomain.no:/home/sb/News/gnussync...
tramp: Decoding remote file /ssh:sb@hjemme.mydomain.no:/home/sb/News/gnussync...
tramp: Decoding remote file /ssh:sb@hjemme.mydomain.no:/home/sb/News/gnussync with function base64-decode-region...
Wrote /tmp/tramp.32266SKR
tramp: Decoding remote file /ssh:sb@hjemme.mydomain.no:/home/sb/News/gnussync...done
tramp: Sending the Perl script `tramp_file_attributes'...done.
gnus-sync: loaded 118 groups (out of 118) from /ssh:sb@hjemme.mydomain.no:News/gnussync
Reading active file from news via nntp...
Reading active file from privat via nnimap...
Opening nnimap server on privat...
Loading tls...done
Opening TLS connection to `imap.mydomain.no'...
Opening TLS connection with `gnutls-cli -p imaps imap.mydomain.no'...failed
Opening TLS connection with `gnutls-cli -p imaps imap.mydomain.no --protocols ssl3'...failed
Opening TLS connection with `openssl s_client -connect imap.mydomain.no:imaps -no_ssl2 -ign_eof'...done
Opening TLS connection to `imap.mydomain.no'...done
Opening nnimap server on privat...failed
Loading utf7...done
Reading active file from privat via nnimap...done
Reading active file from news.gmane.org via nntp...
Opening nntp server on news.gmane.org...failed
Reading active file via nndiary...
Opening nndiary server...failed
Reading active file via nndiary...done
Opening nntp server on news...failed
Loading parse-time...done
Opening nntp server on news.gmane.org...failed
No new newsgroups
Checking new news...
Opening nntp server on news...failed
Opening nntp server on news.gmane.org...failed
Reading active file via nndraft...done
Opening nntp server on news.opera.com...failed
Reading active file via nnml...
Opening nnml server...failed
nnml: Reading incoming mail (no new mail)...done
Reading active file via nnml...done
Opening nntp server on news.eclipse.org...
Unable to open server nntp+news.eclipse.org, go offline? (y or n) 
Opening nntp server on news.eclipse.org...failed
Opening nntp server on dough.gmane.org...failed
Checking new news...done
Loading gnus-topic...done
Retrieving newsgroup: nnimap+privat:dod...
Loading disp-table...done
Loading /home/sb/gmadmin/spam-gmane.el (source)...done
Loading gnus-ml...done
Fetching headers for nnimap+privat:dod...
Read 0KB [1204 times]
Read 2KB [727 times]
mapc: Wrong type argument: char-or-string-p, (nil nil)

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> I had one server that used nnimap-stream shell, and it stopped working
> since we now only support imap and ssl streams now. Any plans of adding
> shell streams back?

It's now back.

> My other nnimap server talked to imap.gmail.com over an ssl stream, but
> it failed to connect because there was no imaps entry in /etc/services
> (this was on Solaris).

Hm...  yes, that has to be fixed.  But where did it bug out?  Did you
get a backtrace?

> Added an entry, and killed the two attempts to connect using
> gnutls-cli (they hung, don't know why, as the commands seem to work
> from a terminal) so that it fell back to using openssl s_client, and
> then I got in.

Huh.

> Haven't got around to testing much yet. The one thing I have noticed is
> that the summary buffer displays question marks instead of the number of
> lines in the messages.

So they do.  That should be easy to fix -- I think I can just ask for
the number of lines...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>> Haven't got around to testing much yet. The one thing I have noticed is
>> that the summary buffer displays question marks instead of the number of
>> lines in the messages.
>
> So they do.  That should be easy to fix -- I think I can just ask for
> the number of lines...

Er, no, I can't.  I can't figure out how to get the number of lines in
the bodies.  Perhaps I have to ask for BODYSTRUCTURE or something.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Er, no, I can't.  I can't figure out how to get the number of lines in
> the bodies.  Perhaps I have to ask for BODYSTRUCTURE or something.

Yeah, that did the trick.  Pushed.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> And a third configuration I have, talking to an IMAP server that doesn't
> identify itself (I *think* it's Zimbra) fails in nnimap-get-groups
> because the second argument in (string-match "noselect" (caadr line)) is
> nil.
>
> This happens because the LIST response from the server doesn't have any
> name attributes. Example:

Oh, darn.  I actually totally forgot to test on the Zimbra server.  I
put it into my conf, and it failed just like yours.  I'll get fixin'.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Oh, darn.  I actually totally forgot to test on the Zimbra server.  I
> put it into my conf, and it failed just like yours.  I'll get fixin'.

Ok; pushed.  I now can start up with all five servers and select
messages from them.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Knut Anders Hatlen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Knut Anders Hatlen <kahatlen@gmail.com> writes:
>
>> And a third configuration I have, talking to an IMAP server that doesn't
>> identify itself (I *think* it's Zimbra) fails in nnimap-get-groups
>> because the second argument in (string-match "noselect" (caadr line)) is
>> nil.
>>
>> This happens because the LIST response from the server doesn't have any
>> name attributes. Example:
>
> Oh, darn.  I actually totally forgot to test on the Zimbra server.  I
> put it into my conf, and it failed just like yours.  I'll get fixin'.

Thanks! The next issue you'll run into is that CAPABILITY says IMAP4REV1
(all uppercase), so the checks for (member "IMAP4rev1" ...)  won't find
it, and that leads to the UID FETCH commands not being accepted.

-- 
Knut Anders

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> Thanks! The next issue you'll run into is that CAPABILITY says IMAP4REV1
> (all uppercase), so the checks for (member "IMAP4rev1" ...)  won't find
> it, and that leads to the UID FETCH commands not being accepted.

So the capabilities are case-insensitive?  Fixed and pushed.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

>  - It says "opening nntp server blah failed" for all of my nntp servers,
>    even though it seems to (at least partly) work.  The one that
>    actually fails ie. news.eclipse.org, fails on old gnus

Huh.  I didn't think I had changed anything in the nntp.el department.
This started just now?

>  - It says failed on the nnimap server as well, but it comes up with the
>    correct new article count, but it fails when trying to enter the
>    group on the server that has the new articles:
>     - It uses a lot of time to read a small amount of data
>     - It fails with the following message in the minibuffer:
> 	mapc: Wrong type argument: char-or-string-p, (nil nil)

Do you have a backtrace?

> Fetching headers for nnimap+privat:dod...
> Read 0KB [1204 times]
> Read 2KB [727 times]

That's s-l-o-w.  I mean, Emacs managed to message that many times while
reading 2KB.

Could you look in the

*nnimap private something something*

buffer and see what's in there?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Knut Anders Hatlen]

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> Oh, darn.  I actually totally forgot to test on the Zimbra server.  I
>> put it into my conf, and it failed just like yours.  I'll get fixin'.
>
> Ok; pushed.  I now can start up with all five servers and select
> messages from them.

Hmm... I still need the patch in one of my earlier posts to fix the
(string-match "noselect" ...) problem. Attaching it again. With that
patch and your latest changes, things seem to work. Thanks!

-- 
Knut Anders

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: nil.diff --]
[-- Type: text/x-patch, Size: 503 bytes --]

diff --git a/lisp/nnimap.el b/lisp/nnimap.el
index 548b6ec..3caa58e 100644
--- a/lisp/nnimap.el
+++ b/lisp/nnimap.el
@@ -416,7 +416,8 @@ not done by default on servers that doesn't support that command.")
     (when (car result)
       (dolist (line (cdr result))
 	(when (and (equal (car line) "LIST")
-		   (not (string-match "noselect" (caadr line))))
+		   (not (and (caadr line)
+			     (string-match "noselect" (caadr line)))))
 	  (push (car (last line)) groups)))
       (nreverse groups))))
 

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> Hmm... I still need the patch in one of my earlier posts to fix the
> (string-match "noselect" ...) problem. Attaching it again. With that
> patch and your latest changes, things seem to work. Thanks!

Sorry; forgot to apply it.

Thanks for the patch; applied and pushed.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Knut Anders Hatlen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Knut Anders Hatlen <kahatlen@gmail.com> writes:
>
>> I had one server that used nnimap-stream shell, and it stopped working
>> since we now only support imap and ssl streams now. Any plans of adding
>> shell streams back?
>
> It's now back.
>
>> My other nnimap server talked to imap.gmail.com over an ssl stream, but
>> it failed to connect because there was no imaps entry in /etc/services
>> (this was on Solaris).
>
> Hm...  yes, that has to be fixed.  But where did it bug out?  Did you
> get a backtrace?

Yes, I got one, but I'm not sure it's very helpful:

Debugger entered--Lisp error: (error "Buffer *nnimap imap.gmail.com nil  *nntpd**<3> has no process")
  process-send-string(nil "56 EXAMINE \"INBOX\"
\n")
  nnimap-send-command("EXAMINE %S" "INBOX")
(...)

The root cause is the call to open-tls-stream from
nnimap-open-connection where the port argument is "imaps" if
nnimap-server-port is nil. The missing entry in /etc/services will make
gnutls-cli and openssl fail when port is imaps:

$ gnutls-cli -p imaps imap.gmail.com  
Resolving 'imap.gmail.com'...
Cannot resolve imap.gmail.com:imaps: service name not available for the specified socket type

The workaround is simple enough; just set nnimap-server-port to 993 in
~/.gnus.

>> Added an entry, and killed the two attempts to connect using
>> gnutls-cli (they hung, don't know why, as the commands seem to work
>> from a terminal) so that it fell back to using openssl s_client, and
>> then I got in.
>
> Huh.

No idea what's going on here. Anyways, it works with openssl, so for now
I'll just remove the gnutls-cli entries from tls-program.

>> Haven't got around to testing much yet. The one thing I have noticed is
>> that the summary buffer displays question marks instead of the number of
>> lines in the messages.
>
> So they do.  That should be easy to fix -- I think I can just ask for
> the number of lines...

This seems to work now. Thanks!

-- 
Knut Anders

Re: Releasing the new nnimap on y'all soon

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

>> mapc: Wrong type argument: char-or-string-p, (nil nil)

> Do you have a backtrace?

>> Fetching headers for nnimap+privat:dod...
>> Read 0KB [1204 times]
>> Read 2KB [727 times]

> That's s-l-o-w.  I mean, Emacs managed to message that many times
> while reading 2KB.

> Could you look in the

> *nnimap private something something*

> buffer and see what's in there?

Too late for both of them.  I've synced and rebuilt and restarted emacs
with gnus twice, since then.  The first sync and build etc. failed
miserably at startup, that's why I did a new one.

Now it sort of seems to work.

That is: I still get the "opening blah blah...failed" messages for both
the nntp servers and my single nnimap server.

However, both the nntp and nnimap servers seems to work.

I was able to read a new message in an nnimap mailbox, and if I can post
this one, I can both read and post to a group on an nntp server that
says:
 Opening nntp server on news.gmane.org...failed

Re: Releasing the new nnimap on y'all soon

[Knut Anders Hatlen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> I'll be releasing the new nnimap later tonight, so be prepared for some
>> breakage.  :-)
>
> I pushed it out now.

And one more problem I've noticed... When entering a group with some
ticked articles (the articles had been ticked with the old nnimap or
with other mail clients), it seems to get confused and sometimes show
the ticked ones as read and the read ones as ticked.

-- 
Knut Anders

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> That is: I still get the "opening blah blah...failed" messages for both
> the nntp servers and my single nnimap server.

Could you try evaling the following?

(gnus-check-server '(nntp "quimby.gnus.org"))

If that says "...failed" in the *Messages* buffer, then something is
really wonky.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> And one more problem I've noticed... When entering a group with some
> ticked articles (the articles had been ticked with the old nnimap or
> with other mail clients), it seems to get confused and sometimes show
> the ticked ones as read and the read ones as ticked.

Hm...  what does `G E' on one of these groups say?  And you say
"sometimes" -- can you see any pattern?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> The root cause is the call to open-tls-stream from
> nnimap-open-connection where the port argument is "imaps" if
> nnimap-server-port is nil. The missing entry in /etc/services will make
> gnutls-cli and openssl fail when port is imaps:

Right.  I think I've now fixed this.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

I haven't written the new documentation for nnimap yet, but I wonder
whether anybody dares setting `nnimap-inbox' in one of their server and
see whether the split gets done correctly.  This is the most scary bit.
:-) 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Could you try evaling the following?

> (gnus-check-server '(nntp "quimby.gnus.org"))

> If that says "...failed" in the *Messages* buffer, then something is
> really wonky.

It did:
 Opening nntp server on quimby.gnus.org...failed

In the *scratch* buffer it said:

(gnus-check-server '(nntp "quimby.gnus.org"))
#<process nntpd<4>>

Re: Releasing the new nnimap on y'all soon

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> I haven't written the new documentation for nnimap yet, but I wonder
> whether anybody dares setting `nnimap-inbox' in one of their server
> and see whether the split gets done correctly.  This is the most scary
> bit.  :-)

Well, I do server side splits, so...

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> It did:
>  Opening nntp server on quimby.gnus.org...failed

Ok, let's try drilling down a bit.

Can you see what the following two eval to in the *scratch* buffer?

(gnus-open-server '(nntp "quimby.gnus.org"))

(nntp-open-server "quimby.gnus.org")

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Can you see what the following two eval to in the *scratch* buffer?

Hang on.  I think I may have found the cause.  Could you pull and test?
And if that doesn't fix it, then eval the two.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Ok, let's try drilling down a bit.

> Can you see what the following two eval to in the *scratch* buffer?

> (gnus-open-server '(nntp "quimby.gnus.org"))

> (nntp-open-server "quimby.gnus.org")

(gnus-open-server '(nntp "quimby.gnus.org"))
#<process nntpd<4>>


(nntp-open-server "quimby.gnus.org")
t

Re: Releasing the new nnimap on y'all soon

[Knut Anders Hatlen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Knut Anders Hatlen <kahatlen@gmail.com> writes:
>
>> And one more problem I've noticed... When entering a group with some
>> ticked articles (the articles had been ticked with the old nnimap or
>> with other mail clients), it seems to get confused and sometimes show
>> the ticked ones as read and the read ones as ticked.
>
> Hm...  what does `G E' on one of these groups say?

For example I have one that looks like this:

("apache.derby-dev" 3
 ((1 . 1685))
 ((seen 596 609 965 1337 1503 1566
        (1592 . 1692))
  (reply
   (1592 . 1640)
   (1642 . 1656)
   (1658 . 1666)
   (1668 . 1692))
  (tick
   (1592 . 1640)
   (1642 . 1656)
   (1658 . 1666)
   (1668 . 1692))))

When I enter the group (by pressing enter, so I won't see read ones) I
see 97 messages, all of which marked as answered (which is not true), 91
of them are marked as ticked, 6 are marked as unread.

The correct should have been 7 unseen and 6 ticked. The rest should be
marked as read.

> And you say "sometimes" -- can you see any pattern?

Well, not really. I haven't found any reliable way to reproduce this
exact problem, but some odd behaviour with flags can be seen by doing
this:

1) Start from scratch by doing rm ~/.newsrc*

2) Start Gnus, enter the server buffer and browse the imap server

3) Subscribe to a group with U

4) Go back to *Groups* and enter the group (without pressing "g" first)

When you enter the summary buffer, you'll see all the mails as unread
and unticked, which is not correct. If you then exit the summary buffer,
press "g", and reenter the group, the flags will be correct.

-- 
Knut Anders

Re: Releasing the new nnimap on y'all soon

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> Can you see what the following two eval to in the *scratch* buffer?

> Hang on.  I think I may have found the cause.  Could you pull and test?
> And if that doesn't fix it, then eval the two.

It still says "...failed", but it still works, and it seems to be a lot
faster. 

Here are the evaluations from *scratch* 

(gnus-open-server '(nntp "quimby.gnus.org"))
#<process nntpd<4>>

(nntp-open-server "quimby.gnus.org")
t

Re: Releasing the new nnimap on y'all soon

[Adam Sjøgren]

On Fri, 17 Sep 2010 23:01:17 +0200, Steinar wrote:

>>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

>> Ok, let's try drilling down a bit.

Hey, I just updated from git (5a76c506), and I get this too.

M-x gnus, in *Messages*:

  Opening TLS connection to `snews.gmane.org'...
  Opening TLS connection with `gnutls-cli -p 563 snews.gmane.org'...
  Opening TLS connection with `gnutls-cli -p 563 snews.gmane.org'...done
  Opening TLS connection to `snews.gmane.org'...done
  Opening nntp server on news.gmane.org...failed
  Opening nntp server on news.gwene.org...
  Opening nntp server on news.gwene.org...failed
  Reading active file from archive via nnml...
  Opening nnml server on archive...
  Opening nnml server on archive...failed
  Reading active file from archive via nnml...
  Reading active file from archive via nnml...done
  Opening nntp server on news.sslug.dk...
  Opening nntp server on news.sslug.dk...failed
  Reading active file via nndraft...
  Reading active file via nndraft...
  Reading active file via nndraft...done
  Loading gnus-topic...
  Loading gnus-topic...done
  Retrieving newsgroup: nntp+news.gmane.org:gmane.emacs.gnus.general...
  Loading disp-table...
  Loading disp-table...done
  Loading gmane...
  Loading gmane...done
  Loading gnus-ml...
  Loading gnus-ml...done
  Opening nntp server on news.gmane.org...
  Opening nntp server on news.gmane.org...failed

In the *Server* buffer, everything seems fine:

       {nnml:archive} (opened)
       {nntp:news.sslug.dk} (opened)
       {nntp:news.gwene.org} (opened)
       {nntp:news.gmane.org} (opened)
       {nnml:} (opened)
       {nntp:news.koldfront.local} (opened)

... and I can read groups as usual.

>> Can you see what the following two eval to in the *scratch* buffer?

>> (gnus-open-server '(nntp "quimby.gnus.org"))

>> (nntp-open-server "quimby.gnus.org")

  (gnus-open-server '(nntp "quimby.gnus.org"))
   --> #<network connection "nntpd<4>" ("nntp" . "quimby.gnus.org") state:run>

  (nntp-open-server "quimby.gnus.org")
   --> t

If I try a second time, I get t from both.


  Best regards,

    Adam

-- 
 "It's my chainsaw                                            Adam Sjøgren
  Division is mine"                                      asjo@koldfront.dk

Re: Releasing the new nnimap on y'all soon

[Adam Sjøgren]

Looking at gnus-open-server in gnus-int.el, I can't see "result" ever
getting a value - I guess that is why it says failed?

What am I overlookin'?

But it also looks like (gnus-server-opened method) always returns nil
inside gnus-open-server?!


  Best regards,

    Adam

-- 
 "It's my chainsaw                                            Adam Sjøgren
  Division is mine"                                      asjo@koldfront.dk

Re: Releasing the new nnimap on y'all soon

[Frank Schmitt]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I'll be releasing the new nnimap later tonight, so be prepared for some
> breakage.  :-)
>
> Katsumi, this should probably not be pushed to the Emacs trunk until all
> the (presumed) problems have been ironed out.

I just tried to toy around with it. For this I created a new Unix user
and started Gnus as this user. I didn't have an authinfo file and
instead of a question asking me for credentials, I just got

Reading active file from ltw via nnimap...
Opening nnimap server on ltw...
Denied server nnimap+ltw                                                 
Opening nnimap server on ltw...failed

and in server buffer 

{nnimap:ltw} (denied)

with the following config in .gnus

(add-to-list 'gnus-secondary-select-methods
             '(nnimap "ltw"
              (nnimap-address "ltw.loris.tv")
              (nnimap-stream ssl)
              (nnimap-authenticator login)))

-- 
Have you ever considered how much text can fit in eighty columns?  Given that a
signature typically contains up to four lines of text, this space allows you to
attach a tremendous amount of valuable information to your messages.  Seize the
opportunity and don't waste your signature on bullshit that nobody cares about.

Re: Releasing the new nnimap on y'all soon

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:
>> - It fails with the following message in the minibuffer:
>> mapc: Wrong type argument: char-or-string-p, (nil nil)

> Do you have a backtrace?

Ok.  Now it started occurring again.  Here's a backtrace from attempting
to enter an nnimap group (I doctored all domain names to avoid addresses
becoming spam food.  I'll send you the undoctered one on email if that's
significant):

Debugger entered--Lisp error: (wrong-type-argument char-or-string-p (nil nil))
  nnheader-insert-nov([534 "Re: [Bernt50] =?iso-8859-1?q?Felles_m=E5ltid_Fredag_=28Intern=29?= " "grande@nt.ntnu.se " "Sun, 11 Jun 2006 23:30:59 +0200 " "<1150061459.448c8b93bccde@webmail.ntnu.se>" "<04161341FDE60141B7640D4E801D11EC01BE090F@TNS-FBU-2E-011.corp.telenor.se> " -1 43 nil ((Id nil nil) (Ip nil) (Queue))])
  mapc(nnheader-insert-nov ([534 "Re: [Bernt50] =?iso-8859-1?q?Felles_m=E5ltid_Fredag_=28Intern=29?= " "grande@nt.ntnu.se " "Sun, 11 Jun 2006 23:30:59 +0200 " "<1150061459.448c8b93bccde@webmail.ntnu.se>" "<04161341FDE60141B7640D4E801D11EC01BE090F@TNS-FBU-2E-011.corp.telenor.se> " -1 43 nil (... ... ...)] [535 "Unable to deliver your message " "Yahoo! Groups <notify@yahoogroups.net> " "27 Jul 2006 06:26:20 -0000 " "<1153981580.118.23161.m33@yahoogroups.net>" nil -1 11 nil (... ... ...)] [536 "Unable to deliver your message " "Yahoo! Groups <notify@yahoogroups.net> " "27 Jul 2006 06:28:00 -0000 " "<1153981680.43.20536.m38@yahoogroups.net>" nil -1 11 nil (... ... ...)] [537 "Geek-treff #3 " "\"Sverre H. Huseby\" <shh@thathost.net> " "Tue, 12 Sep 2006 09:17:13 +0200 " "<20060912071713.GA25941@thathost.net>" nil -1 25 nil (... ... ...)] [539 "Innom Jernia og/eller Clas " "Steinar Bang <steinar@mydomain.se> " "Fri, 06 Oct 2006 15:49:04 +0200 " "<87fye1h7vz.fsf@mydomain.se>" nil -1 5 nil (... ... ...)] [540 "" "Steinar Bang <steinar@mydomain.se> " "Sat, 28 Oct 2006 17:48:46 +0200 " "<87ejsse90h.fsf@mydomain.se>" nil -1 2 nil (... ... ...)] [541 "Cron <sb@doohan> cd public_html/nrk; tar cf hallo_i_uken_`date --rfc-3339=date`.tar hallo_i_uken*.mp3 " "root@mydomain.se (Cron Daemon) " "Sun, 05 Nov 2006 09:56:05 +0100 " "<E1GgdnN-0000FA-00@doohan.mydomain.se>" nil -1 4 nil (... ... ...)] [542 "Re: List of recent files " "Steinar Bang <steinar@mydomain.se> " "Sat, 09 Dec 2006 16:36:40 +0100 " "<87lklhqdx3.fsf@mydomain.se>" "<egeovh$mov$1@utils.eclipse.org> <egh7on$buo$1@utils.eclipse.org> " -1 28 nil (... ... ...)] [543 "Test " "Steinar Bang <steinar.bang@fast.se> " "Wed, 20 Dec 2006 10:26:04 +0100 " "<1166606765.12500.46.camel@localhost.localdomain>" nil -1 3 nil (... ... ...)] [544 "Test til chello fra gmail " "\"Steinar Bang\" <steinarba@gmail.net> " "Wed, 20 Dec 2006 12:19:40 +0100 " "<4b06a0aa0612200319me78b9aald9067ac7da1c02b@mail.gmail.net>" nil -1 1 nil (... ... ...)] [545 "=?iso-8859-1?Q?Sp=F8rreunders=F8kels?= =?iso-8859-1?Q?e?= om inputvalidering " "\"Sverre H. Huseby\" <shh@thathost.net> " "Sun, 25 Feb 2007 22:12:46 +0100 " "<20070225211246.GA24896@thathost.net>" nil -1 258 nil (... ... ...)] [546 "Geek-treff #4 - 27. juni " "\"Sverre H. Huseby\" <shh@thathost.net> " "Fri, 08 Jun 2007 10:23:25 +0200 " "<466911FD.30801@thathost.net>" nil -1 23 nil (... ... ...)] [547 "Cron <sb@doohan> fetchmail --quit " "root@mydomain.se (Cron Daemon) " "Mon, 10 Sep 2007 05:00:01 +0200 " "<E1IUZVJ-00038b-00@doohan.mydomain.se>" nil -1 3 nil (... ... ...)] [548 "Cron <sb@doohan> fetchmail --quit " "root@mydomain.se (Cron Daemon) " "Tue, 11 Sep 2007 05:00:02 +0200 " "<E1IUvys-0003jE-00@doohan.mydomain.se>" nil -1 3 nil (... ... ...)] [549 "Cron <sb@doohan> fetchmail --quit " "root@mydomain.se (Cron Daemon) " "Wed, 12 Sep 2007 05:00:02 +0200 " "<E1IVISQ-0004L4-00@doohan.mydomain.se>" nil -1 3 nil (... ... ...)] [550 "Cron <sb@doohan> fetchmail --quit >/dev/null " "root@mydomain.se (Cron Daemon) " "Thu, 13 Sep 2007 05:00:01 +0200 " "<E1IVevx-0004uZ-00@doohan.mydomain.se>" nil -1 3 nil (... ... ...)] [551 "dnocllew " "Reina iversen <iversen@optomed.de> " "Tue, 18 Sep 2007 14:10:37 +0200 " "<0JOK008C9CHQQE10@no-osl-m323-srv-004-z1.isp.get.se>" nil -1 8 nil (... ... ...)] [552 "Jeg bruker en annen postadresse enn gmail " "\"Arnfinn Bang\" <arnfinn@mydomain.se> " "Sat, 20 Oct 2007 16:25:14 +0200 " "<op.t0h2ccric6x9ah@abacybercom>" nil -1 9 nil (... ... ...)] [553 "Ny e-post adresse " "\"Magne Dahlberg \\(chello\\)\" <magnedah@chello.se> " "Sat, 3 Dec 2005 09:19:27 +0100 " "<007601c5f7e2$47f5fc60$6600a8c0@upc.se>" nil -1 4 nil (... ... ...)] [554 "=?iso-8859-1?Q?Hydrater_p=E5_radio?= " "\"Roar Larsen\" <Roar.Larsen@iku.sintef.se> " "Tue, 6 Dec 2005 14:30:32 +0100 " "<F21BC54F4FC263418E7FAF82E45BF06E581402@gogo.iku.sintef.se>" nil -1 14 nil (... ... ...)] [555 "Replacing libwww with libCurl - asap. " "\"Trond Kristiansen\" <trond.kristiansen@troux.net> " "Tue, 28 Feb 2006 09:17:18 +0100 " "<op.s5oby4ra1gffef@smtp.online.se>" nil -1 132 nil (... ... ...)] [556 "=?ISO-8859-1?Q?Frida_Fredrikke_i_\"Virtuos\",_NRK1_l=F8rdag_11._mars?= " "\"=?ISO-8859-1?Q?Fr=F8ydis_Waaler?=\" <fwaaler@gmail.net> " "Fri, 10 Mar 2006 00:40:30 +0100 " "<4f1483b90603091540h5cf87b2dj44aa9e6f13a6f97@mail.gmail.net>" nil -1 25 nil (... ... ...)] [557 "Julebrev 2006 " "\"Bernt M. Johnsen\" <berntm@gmail.net> " "Fri, 22 Dec 2006 13:46:37 +0100 " "<798e28690612220446l470a44ebof5a9c7b6a39493e8@mail.gmail.net>" nil -1 136 nil (... ... ...)] [559 "hei fra kongen " "kongen@slottet.se " "Mon, 15 Sep 2008 20:58:36 +0200 " "<E1KfJH1-0002WO-00@doohan.mydomain.se>" nil -1 2 nil (... ... ...)] [560 "[Bernt50] I've added you as a friend on Facebook... " "Kristin =?UNKNOWN?Q?S=C3=A6ther?= <invite+mwx55nyx@facebookmail.net> " "Fri, 17 Aug 2007 02:28:44 -0700 " "<111f387e6df8f6174de037028d7d83b8@register.facebook.net>" nil -1 13 nil (... ... ...)] [561 "[Bernt50] I've added you as a friend on Facebook... " "Kristin =?UNKNOWN?Q?S=C3=A6ther?= <invite+mwxaxb4n@facebookmail.net> " "Fri, 17 Aug 2007 02:28:35 -0700 " "<be8b3e7e09c4e76e423559904577bc71@register.facebook.net>" nil -1 13 nil (... ... ...)] [562 "=?UTF-8?Q?Hytte_p=C3=A5_Beitost=C3=B8len!?= " "Kjell Arne Rekaa <kjell.arne.rekaa@gmail.net> " "Tue, 01 Apr 2008 20:29:22 +0100 " "<4a89846b0804011229l1cf426b0mbbf127b0d647df0@mail.gmail.net>" nil -1 10 nil (... ... ...)] [563 "[Fwd: Petter Hesselberg invited you to the event \"Vinderen skoles loppemarked\"...] " "Steinar Bang <steinar.bang@fast.se> " "Tue, 27 May 2008 13:41:04 +0200 " "<1211888464.25045.7.camel@oslbanstelt>" nil -1 1 nil (... ... ...)] [564 "Trip to China 3 - Manzhouli " "Hugh Cowan <hugh4friends@gmail.net> " "Fri, 07 Nov 2008 20:54:37 +1300 " "<bcf9aac00811062354j75d9edd3n98fbb257435bc7d1@mail.gmail.net>" nil -1 16 nil (... ... ...)] [565 "Trip to China 2 - Harbin and Hailar " "Hugh Cowan <hugh4friends@gmail.net> " "Fri, 07 Nov 2008 20:53:26 +1300 " "<bcf9aac00811062353j8c82674pc0b5e4940fca53dc@mail.gmail.net>" nil -1 17 nil (... ... ...)] [566 "Fwd: Invitation to view Jin's and Hugh's Picasa Web Album - Trip to China 1 - Beijing " "Hugh Cowan <hugh4friends@gmail.net> " "Fri, 07 Nov 2008 20:50:50 +1300 " "<bcf9aac00811062350w64d90523t4c0f95d36f5630e1@mail.gmail.net>" nil -1 38 nil (... ... ...)] [567 "CX - Get Together " "Hans Karim Djarraya <Hans.Karim.Djarraya@computas.net> " "Tue, 11 Nov 2008 15:32:58 +0100 " "<495295EE69BB4B4AAE73D1B0D8AD551802B37012@ATLAS.netputas.int>" nil -1 33 nil (... ... ...)] [568 "Velkommen til Morgenbladet-samtalen fredag kl 17.00: Tema TOR ULVEN " "Alf van der Hagen <avdh@morgenbladet.se> " "Wed, 12 Nov 2008 11:13:33 +0100 " "<6057756AEFC4C442AEF812671CFCD72D49DC1C@I2V-E2K3-009.i04.local>" nil -1 47 nil (... ... ...)] [569 "Re: Velkommen til Morgenbladet-samtalen fredag kl 17.00: Tema TOR ULVEN " "Alf van der Hagen <avdh@morgenbladet.se> " "Wed, 12 Nov 2008 11:16:22 +0100 " "<6057756AEFC4C442AEF812671CFCD72D49DC21@I2V-E2K3-009.i04.local>" nil -1 74 nil (... ... ...)] [570 "En julehilsen fra Morgenbladet - og to viktige meldinger " "Alf van der Hagen <avdh@morgenbladet.se> " "Wed, 17 Dec 2008 10:31:31 +0100 " "<6057756AEFC4C442AEF812671CFCD72D5EF656@I2V-E2K3-009.i04.local>" nil -1 79 nil (... ... ...)] [571 "Donere penger til GNU/FSF? " "\"Sverre H. Huseby\" <shh@thathost.net> " "Wed, 21 Jan 2009 00:49:51 +0100 " "<4976631F.5020208@thathost.net>" nil -1 31 nil (... ... ...)] [572 "=?iso-8859-1?Q?Viktig_informasjon_fra_Get_-_unng=E5_svindel_via_din_e-pos?= =?iso-8859-1?Q?tkonto?= " "Get newsletter <newsletter@get.se> " "Fri, 23 Jan 2009 20:56:47 +0100 " "<82fd1c7672c32755d9bf8b90a65c09f6@localhost.localdomain>" nil -1 53 nil (... ... ...)] [573 "New linux-hjelp member " "Yahoo! Groups Notification <notify@yahoogroups.net> " "Thu, 02 Jul 2009 10:13:50 +0000 " "<1246529630.166.71688.m5@yahoogroups.net>" nil -1 24 nil (... ... ...)] [574 "Test from mydomain.se " "Steinar Bang <sb@mydomain.se> " "Fri, 02 Jul 2010 17:07:27 +0100 " "<E1OUilz-0004Gy-HK@stoner.mydomain.se>" nil -1 3 nil (... ... ...)] [581 "=?iso-8859-1?B?SSB0aGluayBJIGz4+Pj4+Pj4dmUgeW91Li4uLi4uLi4=?= " "tlf@getmail.se " "Mon, 19 Jul 2010 20:19:48 +0200 " "<71b089cf2ae81.4c44b364@getmail.se>" nil -1 3 nil (... ... ...)] [582 "Re: I think I =?iso-8859-1?Q?l=F8=F8=F8=F8=F8=F8=F8ve?= you........ " "Steinar Bang <steinar@mydomain.se> " "Mon, 19 Jul 2010 20:21:06 +0200 " "<m3mxtn49kd.fsf@mydomain.se>" "<71b089cf2ae81.4c44b364@getmail.se> " -1 6 nil (... ... ...)] [584 "Unsubscription by linux-hjelp member " "Yahoo! Groups Notification <notify@yahoogroups.net> " "20 Jul 2010 16:03:54 -0000 " "<1279641834.63324.65902.m12@yahoogroups.net>" nil -1 24 nil (... ... ...)] [585 "Unsubscription by linux-hjelp member " "Yahoo! Groups Notification <notify@yahoogroups.net> " "Tue, 20 Jul 2010 16:03:54 +0000 " "<87vd64oyej.fsf@totally-fudged-out-message-id>" nil -1 24 nil (... ... ...)] [588 "Debian package updates on doohan " "root <root@doohan.mydomain.se> " "Sun, 01 Aug 2010 20:29:35 +0200 " "<E1OfdHy-0003rQ-Vx@doohan>" nil -1 55 nil (... ... ...)] [589 "Debian package updates on doohan " "root <root@doohan.mydomain.se> " "Tue, 03 Aug 2010 20:29:46 +0200 " "<E1OgMFG-0006H3-EX@doohan>" nil -1 45 nil (... ... ...)] [590 "Debian package updates on stoner.mydomain.se " "root <root@stoner.mydomain.se> " "Wed, 04 Aug 2010 06:25:10 +0100 " "<E1OgWTW-00025I-4m@stoner.mydomain.se>" nil -1 35 nil (... ... ...)] [607 "=?Cp1252?Q?Orkid=E9kampanje_hos_Interflora!_Perfekte_gaver.?= " "Interflora <interflora@bounce.meint.se> " "Wed, 18 Aug 2010 11:58:05 +0200 (CEST) " "<15831957.316158.1282125492078.JavaMail.mailsender@mta.meint.se>" nil -1 754 nil (... ... ...)] [609 "OBOS Nyhetsbrev: Vinn billetter til Kurt koker hodet " "\"OBOS\" <noreply@obos.anp.se> " "Fri, 20 Aug 2010 04:35:55 +0200 " "<6E010C84EC2C4242B26B039F991BDEC0@obos.anp.se>" nil -1 75 nil (... ... ...)] [615 "Debian package updates on doohan " "root <root@doohan.mydomain.se> " "Mon, 30 Aug 2010 20:30:12 +0200 " "<E1Oq97U-0004G4-48@doohan>" nil -1 39 nil (... ... ...)] [616 "Debian package updates on stoner.mydomain.se " "root <root@stoner.mydomain.se> " "Mon, 30 Aug 2010 21:37:17 +0100 " "<E1OqB6T-0007VO-4K@stoner.mydomain.se>" nil -1 36 nil (... ... ...)] ...))
  nnvirtual-convert-headers()
  gnus-agent-retrieve-headers((534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 558 559 560 563 568 569 571 573 574 575 576 577 578 579 580 581 582 583 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 ...) "nnimap+privat:INBOX" nil)
  gnus-retrieve-headers((534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 558 559 560 563 568 569 571 573 574 575 576 577 578 579 580 581 582 583 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 ...) "nnimap+privat:INBOX" nil)
  gnus-cache-retrieve-headers((534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 558 559 560 563 568 569 571 573 574 575 576 577 578 579 580 581 582 583 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 ...) "nnimap+privat:INBOX" nil)
  gnus-retrieve-headers((534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 558 559 560 563 568 569 571 573 574 575 576 577 578 579 580 581 582 583 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 ...) "nnimap+privat:INBOX" nil)
  gnus-fetch-headers((534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 558 559 560 563 568 569 571 573 574 575 576 577 578 579 580 581 582 583 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 ...))
  gnus-select-newsgroup("nnimap+privat:INBOX" nil nil)
  gnus-summary-read-group-1("nnimap+privat:INBOX" nil t nil nil nil)
  gnus-summary-read-group("nnimap+privat:INBOX" nil t nil nil nil nil)
  gnus-group-read-group(nil t)
  gnus-group-select-group(nil)
  gnus-topic-select-group(nil)
  call-interactively(gnus-topic-select-group)


>> Fetching headers for nnimap+privat:dod...
>> Read 0KB [1204 times]
>> Read 2KB [727 times]

> That's s-l-o-w.  I mean, Emacs managed to message that many times while
> reading 2KB.

> Could you look in the

> *nnimap private something something*

> buffer and see what's in there?

Lines: 43
To: steinar@mydomain.no.
Subject: Debian package updates on stoner.mydomain.no.
Message-Id: <E1Owhuz-0002st-DO@stoner.mydomain.no>.
From: root <root@stoner.mydomain.no>.
Date: Fri, 17 Sep 2010 21:52:25 +0100.
.

(Domain doctored)

Re: Releasing the new nnimap on y'all soon

[Adam Sjøgren]

Perhaps unsurprisingly git bisect'ing looking at when all servers
started to be reported as failing to open points to:

  df6ac45b952171e7e709c1b0bf23cc7346429f81 is the first bad commit
  commit df6ac45b952171e7e709c1b0bf23cc7346429f81
  Author: Lars Magne Ingebrigtsen <larsi@quimbies.gnus.org>
  Date:   Fri Sep 17 18:18:39 2010 +0200

      Reimplement nnimap, and do tweaks to the rest of the code to support that.

Big commits don't lend themselves to bisecting...


  Best regards,

   Adam

-- 
 "It's my chainsaw                                            Adam Sjøgren
  Division is mine"                                      asjo@koldfront.dk

Re: Releasing the new nnimap on y'all soon

[Adam Sjøgren]

On Fri, 17 Sep 2010 23:45:54 +0200, Adam wrote:

>   df6ac45b952171e7e709c1b0bf23cc7346429f81 is the first bad commit

Ok, so this change maybe looks a little fishy:

--- a/lisp/gnus-int.el
+++ b/lisp/gnus-int.el
@@ -179,10 +179,7 @@ If it is down, start it up (again)."
                        (format " on %s" (nth 1 method)))))
       (gnus-run-hooks 'gnus-open-server-hook)
       (prog1
-         (condition-case ()
-             (setq result (gnus-open-server method))
-           (quit (message "Quit gnus-check-server")
-                 nil))
+         (progn (gnus-open-server method))
        (unless silent
          (gnus-message 5 "Opening %s server%s...%s" (car method)
                        (if (equal (nth 1 method) "") ""

? At least it explains why result doesn't get set any more, I think...


  Best regards,

     Adam

-- 
 "It's my chainsaw                                            Adam Sjøgren
  Division is mine"                                      asjo@koldfront.dk

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> ? At least it explains why result doesn't get set any more, I think...

Yup.  Fixed and pushed.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Frank Schmitt <ich@frank-schmitt.net> writes:

> I just tried to toy around with it. For this I created a new Unix user
> and started Gnus as this user. I didn't have an authinfo file and
> instead of a question asking me for credentials, I just got

Yes, that's the intended behaviour.  But I can change it to query the
user for passwords again?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>> I just tried to toy around with it. For this I created a new Unix user
>> and started Gnus as this user. I didn't have an authinfo file and
>> instead of a question asking me for credentials, I just got
>
> Yes, that's the intended behaviour.  But I can change it to query the
> user for passwords again?

D'oh.  I had really meant it to use auth-source.el so that all this
would just work automatically...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> D'oh.  I had really meant it to use auth-source.el so that all this
> would just work automatically...

Hm.  I thought auth-source.el would query for passwords as a fall-back.
Perhaps it should?  Ted?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

>   gnus-agent-retrieve-headers((534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 558 559 560 563 568 569 571 573 574 575 576 577 578 579 580 581 582 583 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 ...) "nnimap+privat:INBOX" nil)

Does this mean that you use nnimap with the Agent?  I haven't tested
that.  I'll do so now.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Steinar Bang <sb@dod.no> writes:
>> gnus-agent-retrieve-headers((534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 558 559 560 563 568 569 571 573 574 575 576 577 578 579 580 581 582 583 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 ...) "nnimap+privat:INBOX" nil)

> Does this mean that you use nnimap with the Agent? 

Yep.

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> Yep.

I've confirmed multiple issues with the agent interaction, and I've
fixed a couple of them, but unfortunately the rest will have to wait
until tomorrow.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Hm.  I thought auth-source.el would query for passwords as a fall-back.
> Perhaps it should?  Ted?

It'd totally rock if it fell back on querying for user name/password,
and then offer to save the credentials.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> It'd totally rock if it fell back on querying for user name/password,
> and then offer to save the credentials.

Never mind.  I'm totally confused.  It does do that.  Only not the user
name.  I'll add that, then.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> I've confirmed multiple issues with the agent interaction, and I've
> fixed a couple of them, but unfortunately the rest will have to wait
> until tomorrow.

Was "not decoding QP in headers in the summary buffer" one of the
issues?

Because I see that.  One example is Adam Sjøgren's name.

Re: Releasing the new nnimap on y'all soon

[Ted Zlatanov]

On Sat, 18 Sep 2010 02:47:15 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> Hm.  I thought auth-source.el would query for passwords as a fall-back.
>> Perhaps it should?  Ted?

LMI> It'd totally rock if it fell back on querying for user name/password,
LMI> and then offer to save the credentials.

I'd be OK with saving, as long as it didn't mangle the file.  I keep
non-netrc information in mine.

Ted

Re: Releasing the new nnimap on y'all soon

[Steinar Bang]

>>>>> Ted Zlatanov <tzz@lifelogs.com>:

> I'd be OK with saving, as long as it didn't mangle the file.  I keep
> non-netrc information in mine.

When saving, it would probably be good practice to enforce restricted
privileges (e.g. user read/write only and no read for group or others on
linux, and whatever is equivalent in other OSes).

Re: Releasing the new nnimap on y'all soon

[Steinar Bang]

>>>>> Steinar Bang <sb@dod.no>:

> Was "not decoding QP in headers in the summary buffer" one of the
> issues?

> Because I see that.  One example is Adam Sjøgren's name.

After a pull this morning, the summary buffer says "Adam Sjøgren".  So
that's been fixed.

Re: Releasing the new nnimap on y'all soon

[Steinar Bang]

>>>>> Steinar Bang <sb@dod.no>:

> After a pull this morning, the summary buffer says "Adam Sjøgren".  So
> that's been fixed.

But that was of course not related to the nnimap changes, since this is
an nntp group...

Oh well!

In any case: it didn't work on my previous pull, but it works after the
latest pull.

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I'd be OK with saving, as long as it didn't mangle the file.  I keep
> non-netrc information in mine.

It could save things via the secret-* stuff, I guess?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> For example I have one that looks like this:
>
> ("apache.derby-dev" 3
>  ((1 . 1685))
>  ((seen 596 609 965 1337 1503 1566
>         (1592 . 1692))
>   (reply
>    (1592 . 1640)
>    (1642 . 1656)
>    (1658 . 1666)
>    (1668 . 1692))
>   (tick
>    (1592 . 1640)
>    (1642 . 1656)
>    (1658 . 1666)
>    (1668 . 1692))))
>
> When I enter the group (by pressing enter, so I won't see read ones) I
> see 97 messages, all of which marked as answered (which is not true), 91
> of them are marked as ticked, 6 are marked as unread.
>
> The correct should have been 7 unseen and 6 ticked. The rest should be
> marked as read.

How odd.  The most mysterious thing is where all the "answered" messages
come from.

Ok...  I think I know how to debug this somewhat easily.

Could you eval the following:

(let ((info (list "apache.derby-dev" 3 nil)))
  (nnimap-retrieve-group-data-early "name.of.imap.server"
                                     (list info))
  info)

Then see what that returns.

After calling that, go to the "*nnimap name.of.imap.server ..." buffer,
and see what the contents there are.  Send both things to me.

> 3) Subscribe to a group with U
>
> 4) Go back to *Groups* and enter the group (without pressing "g" first)
>
> When you enter the summary buffer, you'll see all the mails as unread
> and unticked, which is not correct. If you then exit the summary buffer,
> press "g", and reenter the group, the flags will be correct.

Ah, yes, that one I'm able to reproduce.  I'll have a fix later today.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Could you eval the following:
>
> (let ((info (list "apache.derby-dev" 3 nil)))
>   (nnimap-retrieve-group-data-early "name.of.imap.server"
>                                      (list info))
>   info)

I meant:

(let ((info (list "apache.derby-dev" 3 nil)))
  (nnimap-finish-retrieve-group-infos
   "name.of.imap.server"
   (list info)
   (nnimap-retrieve-group-data-early "name.of.imap.server"
                                      (list info)))
  info)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Sebastian Krause]

Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> Frank Schmitt <ich@frank-schmitt.net> writes:
>> I just tried to toy around with it. For this I created a new Unix user
>> and started Gnus as this user. I didn't have an authinfo file and
>> instead of a question asking me for credentials, I just got
>
> Yes, that's the intended behaviour.  But I can change it to query the
> user for passwords again?

I actually have the opposite problem: It's asking me for my username
and password, even though I have an authinfo entry:

machine imap.gmail.com login user@example.com password mypassword port 993

This entry used to work with the old nnimap. Has the format changed?

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Sebastian Krause <sebastian@realpath.org> writes:

> I actually have the opposite problem: It's asking me for my username
> and password, even though I have an authinfo entry:
>
> machine imap.gmail.com login user@example.com password mypassword port 993

Ah.  It's now looking for "imaps" instead of "993".  I'll fix it (in a
couple of hours).

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> 1) Start from scratch by doing rm ~/.newsrc*
>
> 2) Start Gnus, enter the server buffer and browse the imap server
>
> 3) Subscribe to a group with U
>
> 4) Go back to *Groups* and enter the group (without pressing "g" first)
>
> When you enter the summary buffer, you'll see all the mails as unread
> and unticked, which is not correct. If you then exit the summary buffer,
> press "g", and reenter the group, the flags will be correct.

I think this should be fixed with the latest push, but I'm not 95%
sure...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Sebastian Krause <sebastian@realpath.org> writes:

> I actually have the opposite problem: It's asking me for my username
> and password, even though I have an authinfo entry:
>
> machine imap.gmail.com login user@example.com password mypassword port 993

This is now fixed and pushed.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Knut Anders Hatlen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Knut Anders Hatlen <kahatlen@gmail.com> writes:
>
>> 1) Start from scratch by doing rm ~/.newsrc*
>>
>> 2) Start Gnus, enter the server buffer and browse the imap server
>>
>> 3) Subscribe to a group with U
>>
>> 4) Go back to *Groups* and enter the group (without pressing "g" first)
>>
>> When you enter the summary buffer, you'll see all the mails as unread
>> and unticked, which is not correct. If you then exit the summary buffer,
>> press "g", and reenter the group, the flags will be correct.
>
> I think this should be fixed with the latest push, but I'm not 95%
> sure...

Yes, this seems to work now. Thanks!

-- 
Knut Anders

Re: Releasing the new nnimap on y'all soon

[Knut Anders Hatlen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> Knut Anders Hatlen <kahatlen@gmail.com> writes:
>>
>>> 1) Start from scratch by doing rm ~/.newsrc*
>>>
>>> 2) Start Gnus, enter the server buffer and browse the imap server
>>>
>>> 3) Subscribe to a group with U
>>>
>>> 4) Go back to *Groups* and enter the group (without pressing "g" first)
>>>
>>> When you enter the summary buffer, you'll see all the mails as unread
>>> and unticked, which is not correct. If you then exit the summary buffer,
>>> press "g", and reenter the group, the flags will be correct.
>>
>> I think this should be fixed with the latest push, but I'm not 95%
>> sure...
>
> Yes, this seems to work now. Thanks!

Oh, well... Almost...

If I press "g" more than twice in the group buffer, the unread count for
each nnimap group is reduced by one, and the ticks are gone when I enter
the groups in that state. I don't think this happened before. Entering
and leaving the group, followed by pressing "g" again, restores the
unread count and the flags.

-- 
Knut Anders

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> If I press "g" more than twice in the group buffer, the unread count for
> each nnimap group is reduced by one, and the ticks are gone when I enter
> the groups in that state. I don't think this happened before. Entering
> and leaving the group, followed by pressing "g" again, restores the
> unread count and the flags.

Weird.  I've tried entering groups, `M-g'-ing them and `g'-ing them in
different orders, but I can't get this to happen.  Do you have a recipe
that makes this happen?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Austin F. Frank]

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]

Should client side splitting via nnimap-split-rule be working with the
new nnimap?  Mine is not.  I'm happy to help debug in whatever way is
most useful.

Currently all new messages on the "dc" server stay in nnimap+dc:INBOX,
but I expect them to be sorted according to the rules in
nnimap-split-fancy.

#v+
(setq nnimap-split-inbox '("INBOX")
      nnimap-split-predicate "UNDELETED"
      nnimap-split-rule '(("dc" ("INBOX" nnimap-split-fancy)))
      nnimap-split-fancy
      '("X-Spam-Flag" "YES.*" "mail.spam"))
#v-

Thanks for any tips,
/au
      
-- 
Austin Frank
http://aufrank.net
GPG Public Key (D7398C2F): http://aufrank.net/personal.asc

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: Releasing the new nnimap on y'all soon

[Knut Anders Hatlen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Knut Anders Hatlen <kahatlen@gmail.com> writes:
>
>> If I press "g" more than twice in the group buffer, the unread count for
>> each nnimap group is reduced by one, and the ticks are gone when I enter
>> the groups in that state. I don't think this happened before. Entering
>> and leaving the group, followed by pressing "g" again, restores the
>> unread count and the flags.
>
> Weird.  I've tried entering groups, `M-g'-ing them and `g'-ing them in
> different orders, but I can't get this to happen.  Do you have a recipe
> that makes this happen?

Seems it only happens with groups that have ticked articles. Seen with
both Zimbra and GMail.

This seems to always trigger it in my setups:

1. Remove ~/.newsrc*

2. Start Gnus and enter server buffer

3. Browse the IMAP server and subscribe to some groups

4. In group buffer, press "g", and all the unread counts will be shown
correctly

5. For each extra time I press "g" the unread count is reduced by one
for all groups that have ticked articles

-- 
Knut Anders

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

"Austin F. Frank" <austin.frank@gmail.com> writes:

> Should client side splitting via nnimap-split-rule be working with the
> new nnimap?  Mine is not.  I'm happy to help debug in whatever way is
> most useful.

You have to set nnimap-inbox to a mailbox.  This was to avoid triggering
the mail splitting code for people who aren't testing that.

You also have to set nnimap-split-methods to a split method, but the
syntax is not the same as in the old nnimap, but is the same as the
syntax for nnmail-split-methods.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> 4. In group buffer, press "g", and all the unread counts will be shown
> correctly
>
> 5. For each extra time I press "g" the unread count is reduced by one
> for all groups that have ticked articles

Could you get the output from one of these groups with `G E' after the
first `g' and after the second `g'?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Knut Anders Hatlen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Dan Christensen <jdc@uwo.ca> writes:
>
>> Should it be mostly a drop-in replacement?  For example, there are two
>> IMAP servers I currently access, one using a shell connection and the
>> other using a network connection:
>>
>>       (setq imap-shell-program '("ssh %s dovecot --exec-mail imap"))
>
> This one is not supported.
>
>>       (add-to-list 'gnus-secondary-select-methods
>> 		   '(nnimap "jdc"
>> 			    (nnimap-address "remote.imap.server")
>> 			    ;(nnimap-server-port XXXXX)
>> 			    ;(nnimap-authenticator login)
>> 			    (nnimap-stream shell)
>
> Ah, I've forgotten to implement the shell thing for nnimap-stream, so
> that won't work.  I'll get to it.

I saw that you added it back. Thanks! A couple of issues:

1) The old nnimap used (nnimap-stream shell) whereas the new nnimap uses
(nnimap-stream stream). Change it back to shell for backwards
compatibility?

2) My imap-shell-program is set to dovecot --exec-mail imap, similar to
what Dan posted above, only that I run it against local mailboxes and
don't need ssh. When I start Gnus, I'm prompted for user name and
password, but the session is pre-authenticated, so that shouldn't be
needed. After typing user name and password, it just hangs, presumably
because the IMAP session starts with PREAUTH and not with the usual OK:

$ /usr/sbin/dovecot -c /home/kah/dovecot.conf --exec-mail imap
* PREAUTH [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS] Logged in as kah

If the session starts with a PREAUTH response, no LOGIN command should
be sent, I think.

-- 
Knut Anders

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> 1) The old nnimap used (nnimap-stream shell) whereas the new nnimap uses
> (nnimap-stream stream). Change it back to shell for backwards
> compatibility?

Typo -- fixed and pushed.

> 2) My imap-shell-program is set to dovecot --exec-mail imap, similar to
> what Dan posted above, only that I run it against local mailboxes and
> don't need ssh. When I start Gnus, I'm prompted for user name and
> password, but the session is pre-authenticated, so that shouldn't be
> needed. After typing user name and password, it just hangs, presumably
> because the IMAP session starts with PREAUTH and not with the usual OK:
>
> $ /usr/sbin/dovecot -c /home/kah/dovecot.conf --exec-mail imap
> * PREAUTH [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS] Logged in as kah

Oh, right.  I didn't know about PREAUTH.  I'll get it fixed.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Knut Anders Hatlen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Knut Anders Hatlen <kahatlen@gmail.com> writes:
>
>> 4. In group buffer, press "g", and all the unread counts will be shown
>> correctly
>>
>> 5. For each extra time I press "g" the unread count is reduced by one
>> for all groups that have ticked articles
>
> Could you get the output from one of these groups with `G E' after the
> first `g' and after the second `g'?

Output from first, second and third "g" below. The first two times the
unread count is shown correctly (3). The third time it's 2.

("nnimap+gmail:INBOX" 5
 ((1 . 4678))
 ((seen 3017 3078 3470 3982 3994 4009 4023 4076 4283 4290 4295 4503 4539 4560 4587 4591 4596 4618 4643 4652
        (4660 . 4681))
  (tick 4503 4560))
 "nnimap:gmail"
 ((imap-status . "4679 3017 4678")
  (uidvalidity . "2")))

("nnimap+gmail:INBOX" 5
 ((1 . 4678))
 ((tick 4503 4560)
  (active 3017 . 4681)
  (seen 3017 3078 3470 3982 3994 4009 4023 4076 4283 4290 4295 4503 4539 4560 4587 4591 4596 4618 4643 4652
        (4660 . 4681)))
 "nnimap:gmail"
 ((imap-status . "4679 3017 4678")
  (uidvalidity . "2")))

("nnimap+gmail:INBOX" 5
 ((1 . 4581)
  (4581 . 4678))
 ((tick 4581 . 4681)
  (active 3017 . 4681)
  (seen 3017 3078 3470 3982 3994 4009 4023 4076 4283 4290 4295 4503 4539 4560 4587 4591 4596 4618 4643 4652
        (4660 . 4681)))
 "nnimap:gmail"
 ((imap-status . "4679 3017 4678")
  (uidvalidity . "2")))


-- 
Knut Anders

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Oh, right.  I didn't know about PREAUTH.  I'll get it fixed.

I don't have a PREAUTH server to test with, but the fix I pushed out now
might work...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> Output from first, second and third "g" below. The first two times the
> unread count is shown correctly (3). The third time it's 2.
>
> ("nnimap+gmail:INBOX" 5
>  ((1 . 4678))

[...]

>  ((1 . 4581)
>   (4581 . 4678))

I think I may have an inkling of an idea what may be causing this -- it
might be the range calculations done when just updating the last 100
flags on subsequent updates.  I'll try to reproduce the bug.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I think I may have an inkling of an idea what may be causing this -- it
> might be the range calculations done when just updating the last 100
> flags on subsequent updates.  I'll try to reproduce the bug.

Yup; there was an off-by-one error in that code.  It now works for me in
my test case.  Could you test your?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Knut Anders Hatlen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> I think I may have an inkling of an idea what may be causing this -- it
>> might be the range calculations done when just updating the last 100
>> flags on subsequent updates.  I'll try to reproduce the bug.
>
> Yup; there was an off-by-one error in that code.  It now works for me in
> my test case.  Could you test your?

The unread count in the group buffer looks correct now, but pressing "g"
multiple times still messes up ticks and other flags.

Take my GMail inbox. At first it is shown fine, with G E displaying:

("nnimap+gmail:INBOX" 5
 ((1 . 4678)
  (4681 . 4682))
 ((seen 3017 3078 3470 3982 3994 4009 4023 4076 4283 4290 4295 4503 4539 4560 4587 4591 4596 4618 4643 4652
        (4660 . 4682))
  (reply 4681)
  (tick 4503 4560 4682))
 "nnimap:gmail"
 ((imap-status . "4679 3017 4678")
  (uidvalidity . "2")))

One replied mail and three ticked is correct.

Then I press "g" twice, and I get the following:

("nnimap+gmail:INBOX" 5
 ((1 . 4678)
  (4681 . 4682))
 ((reply
   (4582 . 4680)
   4682 4681)
  (tick 4582 . 4682)
  (active 3017 . 4682)
  (seen 3017 3078 3470 3982 3994 4009 4023 4076 4283 4290 4295 4503 4539 4560 4587 4591 4596 4618 4643 4652
        (4660 . 4682)))
 "nnimap:gmail"
 ((imap-status . "4679 3017 4678")
  (uidvalidity . "2")))

When I enter the inbox, I see all the mails marked as replied, and also
all except the two unread ones are ticked.

-- 
Knut Anders

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> The unread count in the group buffer looks correct now, but pressing "g"
> multiple times still messes up ticks and other flags.

One further problem with partial marks updates, apparently.  I think
I've fixed that, too.

To get a complete marks sync, you can use a `M-g' on a group.  That'll
make Gnus download all the marks in the group from the IMAP server.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Knut Anders Hatlen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Knut Anders Hatlen <kahatlen@gmail.com> writes:
>
>> The unread count in the group buffer looks correct now, but pressing "g"
>> multiple times still messes up ticks and other flags.
>
> One further problem with partial marks updates, apparently.  I think
> I've fixed that, too.
>
> To get a complete marks sync, you can use a `M-g' on a group.  That'll
> make Gnus download all the marks in the group from the IMAP server.

Seems to work now. Thanks!

-- 
Knut Anders

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> One further problem with partial marks updates, apparently.  I think
> I've fixed that, too.

I bet you all wonder what the bug was.  Right!?

It was that I misread the documentation to gnus-range-difference, so I
thought the order of the arguments didn't matter.  But they do:

(gnus-range-difference '(2 3 4 5) '(3 . 9))
=>
(2)

(gnus-range-difference '(3 . 9) '(2 3 4 5))
=>
((6 . 9))

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Knut Anders Hatlen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> Oh, right.  I didn't know about PREAUTH.  I'll get it fixed.
>
> I don't have a PREAUTH server to test with, but the fix I pushed out now
> might work...

It didn't, but I don't see exactly what's wrong. It hangs while reading
the response from the CAPABILITY command. The *nnimap <server>* buffer
says:

* CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS
64 OK Capability completed.
* BAD Error in IMAP command : Unknown command.

Because of the BAD response after the OK response,
nnimap-wait-for-response doesn't see the OK on the previous line.

Not sure why the BAD response is returned. It as if an empty line had
been appended to the CAPABILITY command, but when I edebugged it, the
command looked fine ("64 CAPABILITY\r\n").

-- 
Knut Anders

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> Not sure why the BAD response is returned. It as if an empty line had
> been appended to the CAPABILITY command, but when I edebugged it, the
> command looked fine ("64 CAPABILITY\r\n").

Could it have been sending more commands?  Look in the "*imap log*"
buffer. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Knut Anders Hatlen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Knut Anders Hatlen <kahatlen@gmail.com> writes:
>
>> Not sure why the BAD response is returned. It as if an empty line had
>> been appended to the CAPABILITY command, but when I edebugged it, the
>> command looked fine ("64 CAPABILITY\r\n").
>
> Could it have been sending more commands?  Look in the "*imap log*"
> buffer. 

No, it only shows the one CAPABILITY command. Both OK and BAD pop up in
the *nnimap...* buffer once the process-send-string has been called on
the above string.

-- 
Knut Anders

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> No, it only shows the one CAPABILITY command. Both OK and BAD pop up in
> the *nnimap...* buffer once the process-send-string has been called on
> the above string.

I have no idea what the untagged BAD means, but Gnus should be able to
parse it, anyway.  It's valid for the server to add more stuff after
it's sent the stuff we asked for.

I've now made this change and pushed it out.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Knut Anders Hatlen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> Knut Anders Hatlen <kahatlen@gmail.com> writes:
>>
>>> Not sure why the BAD response is returned. It as if an empty line had
>>> been appended to the CAPABILITY command, but when I edebugged it, the
>>> command looked fine ("64 CAPABILITY\r\n").
>>
>> Could it have been sending more commands?  Look in the "*imap log*"
>> buffer. 
>
> No, it only shows the one CAPABILITY command. Both OK and BAD pop up in
> the *nnimap...* buffer once the process-send-string has been called on
> the above string.

I pointed nnimap-shell-program to a script that prints "* PREAUTH\r\n"
and writes all its input to a file. It turned out that the "\r\n" that
nnimap sends has been transformed to "\n\n" when it arrives the shell
script.

Looking at how the old nnimap did it, I found that imap-shell-open
changed imap-client-eol from "\r\n" to "\n", presumably because of the
same problem.

-- 
Knut Anders

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> Looking at how the old nnimap did it, I found that imap-shell-open
> changed imap-client-eol from "\r\n" to "\n", presumably because of the
> same problem.

Yes, sounds likely.  Does the text that comes back from the shell
connection have \r\n, or just \n?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Knut Anders Hatlen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Knut Anders Hatlen <kahatlen@gmail.com> writes:
>
>> No, it only shows the one CAPABILITY command. Both OK and BAD pop up in
>> the *nnimap...* buffer once the process-send-string has been called on
>> the above string.
>
> I have no idea what the untagged BAD means, but Gnus should be able to
> parse it, anyway.  It's valid for the server to add more stuff after
> it's sent the stuff we asked for.
>
> I've now made this change and pushed it out.

That did the trick. I can now use shell streams. Looking in the logs,
every good response from the server is followed by an untagged bad
response, so we should probably also switch from \r\n to \n for shell
streams.

-- 
Knut Anders

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> Looking at how the old nnimap did it, I found that imap-shell-open
> changed imap-client-eol from "\r\n" to "\n", presumably because of the
> same problem.

I've now pushed a fix that makes 'shell connections just do \r\n on
commands.  I'm not totally sure that's the right thing in all
circumstances -- but give it a whirl.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Knut Anders Hatlen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Knut Anders Hatlen <kahatlen@gmail.com> writes:
>
>> Looking at how the old nnimap did it, I found that imap-shell-open
>> changed imap-client-eol from "\r\n" to "\n", presumably because of the
>> same problem.
>
> Yes, sounds likely.  Does the text that comes back from the shell
> connection have \r\n, or just \n?

The responses have \r\n.

-- 
Knut Anders

Re: Releasing the new nnimap on y'all soon

[Knut Anders Hatlen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Knut Anders Hatlen <kahatlen@gmail.com> writes:
>
>> Looking at how the old nnimap did it, I found that imap-shell-open
>> changed imap-client-eol from "\r\n" to "\n", presumably because of the
>> same problem.
>
> I've now pushed a fix that makes 'shell connections just do \r\n on
> commands.  I'm not totally sure that's the right thing in all
> circumstances -- but give it a whirl.

Works great! Thanks!

And did I mention that the new nnimap is fast? :)

-- 
Knut Anders

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> And did I mention that the new nnimap is fast? :)

Yay!  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Sebastian Krause]

Some new problem I've had two times today: After my laptop had been
in Suspend-to-RAM for a while (I always suspend my computer if I
leave it for more than half an hour or so), I pressed "g" and Gnus
reconnected to all servers except for IMAP:

,----
| Opening nntp server on news.hansenet.de...done
| Opening nntp server on news.gmane.org...done
| Opening TLS connection to `imap.gmail.com'...
| Opening TLS connection with `gnutls-cli -p 993 imap.gmail.com'...failed
| Opening TLS connection with `gnutls-cli -p 993 imap.gmail.com --protocols ssl3'...failed
| Opening TLS connection with `openssl s_client -connect imap.gmail.com:993 -no_ssl2 -ign_eof'...done
| Opening TLS connection to `imap.gmail.com'...done
`----

After the last line it just hung until pressing C-g. I've now
installed gnutls-bin because it might work better, but is there any
way I can find out why it doesn't reconnect?

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Sebastian Krause <sebastian@realpath.org> writes:

> After the last line it just hung until pressing C-g. I've now
> installed gnutls-bin because it might work better, but is there any
> way I can find out why it doesn't reconnect?

Hm...

Could you try to go to the *imap imap.gmail.com...* buffer and say:

(process-status (get-buffer-process (current-buffer)))

If it says `run', then that means that Emacs thinks that the connection
is still valid.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Knut Anders Hatlen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Knut Anders Hatlen <kahatlen@gmail.com> writes:
>
>> Looking at how the old nnimap did it, I found that imap-shell-open
>> changed imap-client-eol from "\r\n" to "\n", presumably because of the
>> same problem.
>
> I've now pushed a fix that makes 'shell connections just do \r\n on
> commands.  I'm not totally sure that's the right thing in all
> circumstances -- but give it a whirl.

For the record, there's a bug report on this problem in the Emacs bug
tracker: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1523

-- 
Knut Anders

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> For the record, there's a bug report on this problem in the Emacs bug
> tracker: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1523

Hm.  I got to wondering what tls.el did.  I mean, it's also talking to a
process.

It turns out it binds `process-connection-type' to nil.  Perhaps the
shell thing should do it to?  I'll try it, remove the "\n" thing, and
we'll see what happens.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Knut Anders Hatlen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Knut Anders Hatlen <kahatlen@gmail.com> writes:
>
>> For the record, there's a bug report on this problem in the Emacs bug
>> tracker: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1523
>
> Hm.  I got to wondering what tls.el did.  I mean, it's also talking to a
> process.
>
> It turns out it binds `process-connection-type' to nil.  Perhaps the
> shell thing should do it to?  I'll try it, remove the "\n" thing, and
> we'll see what happens.

Sounds like the right thing to do. It still works. And there are no BAD
responses in *nnimap...*.

-- 
Knut Anders

Re: Releasing the new nnimap on y'all soon

[Sebastian Krause]

Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> Sebastian Krause <sebastian@realpath.org> writes:
>> After the last line it just hung until pressing C-g. I've now
>> installed gnutls-bin because it might work better, but is there any
>> way I can find out why it doesn't reconnect?
>
> Hm...
>
> Could you try to go to the *imap imap.gmail.com...* buffer and say:
>
> (process-status (get-buffer-process (current-buffer)))
>
> If it says `run', then that means that Emacs thinks that the connection
> is still valid.

I actually just realized that this problem doesn't only happen after
a suspend, but also when I have Gnus idle for so time (maybe more
than an hour or so). Since Emacs is completely unresponsive until I
hit C-g, I can only look into the buffers after that.

*nnimap imap.gmail.com...* shows this:

,----
| *** Fatal error: A TLS packet with unexpected length was received.
| *** Server has terminated the connection abnormally.
| 
| Process *nnimap* exited abnormally with code 1
`----

And this is what happens when I run your code from above in the
buffer:

,----
| Debugger entered--Lisp error: (error "Buffer *nnimap imap.gmail.com 993  *nntpd** has no process")
|   process-status(nil)
|   eval((process-status (get-buffer-process (current-buffer))))
|   eval-last-sexp-1(nil)
|   eval-last-sexp(nil)
|   call-interactively(eval-last-sexp nil nil)
`----

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Sebastian Krause <sebastian@realpath.org> writes:

> I actually just realized that this problem doesn't only happen after
> a suspend, but also when I have Gnus idle for so time (maybe more
> than an hour or so). Since Emacs is completely unresponsive until I
> hit C-g, I can only look into the buffers after that.
>
> *nnimap imap.gmail.com...* shows this:

Hm...  I wonder what's breaking here.

If I try to do a

(kill-process (get-buffer-process (current-buffer)))

in the gmail buffer, and then do a `g', then Gnus reconnects as
expected.

Hm.  Could you try `(setq debug-on-quit t)', `C-g' when it hangs and
mail me the backtrace?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Ted Zlatanov]

On Sat, 18 Sep 2010 09:05:32 +0200 Steinar Bang <sb@dod.no> wrote: 

>>>>>> Ted Zlatanov <tzz@lifelogs.com>:
>> I'd be OK with saving, as long as it didn't mangle the file.  I keep
>> non-netrc information in mine.

SB> When saving, it would probably be good practice to enforce restricted
SB> privileges (e.g. user read/write only and no read for group or others on
SB> linux, and whatever is equivalent in other OSes).

I think it should only append to the file, never create it.  That avoids
this particular security issue since file permissions are not changed on append.

On Sat, 18 Sep 2010 13:51:37 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> It could save things via the secret-* stuff, I guess?

You mean the Secrets API?

Ted

Re: Releasing the new nnimap on y'all soon

[Steinar Bang]

In case anyone cares: it compiles on emacs 21.3, and even starts, but doesn't
work.

The buffer "*nnimap imap.mydomain.no nil  *nntpd**" contains the contents:

1 OK Logged in.
* BYE Disconnected for inactivity.
Process *nnimap* finished

(The BYE stuff came later, after the emacs had been hanging there for a while). 

The *Messages* buffer is unclear on whether the nnimap server succeeded in
being opened or not (it says it failed to open, but it repeats the
messages about reading the active information):

Reading active file from news via nntp...
Reading active file from privat via nnimap...
Opening nnimap server on privat...
Loading tls...done
Opening TLS connection to `imap.mydomain.no'...
Opening TLS connection with `gnutls-cli -p imaps imap.mydomain.no'...failed
Opening TLS connection with `gnutls-cli -p imaps imap.mydomain.no --protocols ssl3'...failed
Opening TLS connection with `openssl s_client -connect imap.mydomain.no:imaps -no_ssl2 -ign_eof'...done
Opening TLS connection to `imap.mydomain.no'...done
Unable to open server nnimap+privat due to: Wrong number of arguments: #[(string &optional separators) "\b\206\306\307\310\211\x1c\311\f
\203&\v\307\224U\203&\vGW\203&\vT\202'\v#\203Y\307\224GW\203Y\312\307\224\307=\204S\307\224\307\225=\203K\307\224\v=\204S\v\307\224O	B\307\225\202\f\vG=\204g\v\310O	B	\237,\207" [separators list notfirst start rexp string "[ \f	
\v]+" 0 nil string-match t] 5 1387300], 3
Opening nnimap server on privat...done
Reading active file from privat via nnimap...done
Reading active file from news.gmane.org via nntp...
Opening nntp server on news.gmane.org...done
Reading active file via nndiary...
Opening nndiary server...done
Reading active file via nndiary...done
Opening nntp server on news...done
Loading parse-time...done
Opening nntp server on news.gmane.org...done
No new newsgroups
Checking new news...
Opening nntp server on news...done
Reading active file from privat via nnimap...done
Opening nntp server on news.gmane.org...done
Reading active file via nndraft...done
Opening nntp server on news.opera.com...done
Reading active file via nnml...
Opening nnml server...done
Loading byte-opt...done
Reading active file via nnml...done
Opening nntp server on news.eclipse.org...
Denied server nntp+news.eclipse.org
Opening nntp server on news.eclipse.org...failed
Quit opening connection to news.eclipse.org

"Format specifier doesn't match argument type" error message when exiting nnimap group (Was: Releasing the new nnimap on y'all soon)

[Steinar Bang]

System: RHEL4, Intel P4
	GNU Emacs 22.3
	gnus git pull from this morning (and still up to date)
	agent on all nnimap and nntp groups

When exiting one particular nnimap group, I get the error message
 Format specifier doesn't match argument type
and then it refuses to exit that group.

I have to leave with `Q' instead.

Any ideas what might cause this?

Here are the messages from entering and exiting the group in the
*Messages* buffer:

Fetching headers for nnimap+privat:getmail...done
Generating summary...done
No more unseen articles
No more unread articles
Exiting summary buffer and applying spam rules
nnimap-wait-for-response: Format specifier doesn't match argument type
Discard changes to this group and exit? (y or n) 

Re: "Format specifier doesn't match argument type" error message when exiting nnimap group

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> Exiting summary buffer and applying spam rules
> nnimap-wait-for-response: Format specifier doesn't match argument type

I think it's likely that this is fixed by David's patch.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> LMI> It could save things via the secret-* stuff, I guess?
>
> You mean the Secrets API?

Yes, I guess?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: "Format specifier doesn't match argument type" error message when exiting nnimap group

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Steinar Bang <sb@dod.no> writes:
>> Exiting summary buffer and applying spam rules
>> nnimap-wait-for-response: Format specifier doesn't match argument type

> I think it's likely that this is fixed by David's patch.

Yes it did.  But the read count updated by the visit wasn't persisted.
A new `g' made the group show 1 unread article again.

David said he had seen the same thing and thought it was unrelated to
the patch.

Re: Releasing the new nnimap on y'all soon

[Ted Zlatanov]

On Mon, 20 Sep 2010 18:25:17 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
LMI> It could save things via the secret-* stuff, I guess?
>> 
>> You mean the Secrets API?

LMI> Yes, I guess?

`auth-source-create' already does this.  It's invoked when the
CREATE-IF-MISSING parameter to `auth-source-user-or-password' is set.
There's also a DELETE-EXISTING parameter there.

So `auth-source-create' needs to be augmented to support netrc saves, I
think, to provide the requested features.  It's not hard so I'll get to
it eventually unless someone beats me to it.

Ted

Persistent 1 unread count on nnimap group (Was: "Format specifier doesn't match argument type" error message when exiting nnimap group)

[Steinar Bang]

>>>>> Steinar Bang <sb@dod.no>:

> A new `g' made the group show 1 unread article again.

> David said he had seen the same thing and thought it was unrelated to
> the patch.

Here's the result of `G E' on that group:
("nnimap+privat:getmail" 2
 ((1 . 45))
 ((reply 28)
  (tick 25
        (30 . 31))
  (active 1 . 46)
  (seen
   (25 . 28)
   (30 . 31)
   (46 . 47)))
 "nnimap:privat"
 ((imap-status . "48 1 47")
  (uidvalidity . "1279388661")))

I don't know what the numbers mean, but I see (1 . 45) at the top, and
then (active 1 . 46) and then (46 . 47) under (seen.

Could it be that there is a mismatch in what number of articles nnimap
believes it has?  Ie. either the (seen has two more than the (1 . 45) at the
start, or one more than the (active 1 . 46)...?

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> `auth-source-create' already does this.  It's invoked when the
> CREATE-IF-MISSING parameter to `auth-source-user-or-password' is set.
> There's also a DELETE-EXISTING parameter there.

CREATE-IF-MISSING is being passed to the thing, but it doesn't save
anything for me.

> So `auth-source-create' needs to be augmented to support netrc saves, I
> think, to provide the requested features.  It's not hard so I'll get to
> it eventually unless someone beats me to it.

Even though a netrc file exists, shouldn't it save new passwords to the
.gpg file?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: "Format specifier doesn't match argument type" error message when exiting nnimap group

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> Yes it did.  But the read count updated by the visit wasn't persisted.
> A new `g' made the group show 1 unread article again.

I got the opposite result -- `M-g' made the empty group say that it had
1 article.  I've now fixed this.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Ted Zlatanov]

On Tue, 21 Sep 2010 18:06:53 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> `auth-source-create' already does this.  It's invoked when the
>> CREATE-IF-MISSING parameter to `auth-source-user-or-password' is set.
>> There's also a DELETE-EXISTING parameter there.

LMI> CREATE-IF-MISSING is being passed to the thing, but it doesn't save
LMI> anything for me.

It only creates if your sources include the Secrets API.  See
`auth-source-create'.

>> So `auth-source-create' needs to be augmented to support netrc saves, I
>> think, to provide the requested features.  It's not hard so I'll get to
>> it eventually unless someone beats me to it.

LMI> Even though a netrc file exists, shouldn't it save new passwords to the
LMI> .gpg file?

No, it will save to whatever is in the spec.  So if the spec says
'secrets then it saves to Secrets API (this is working thanks to help
from Michael Albinus).  If the spec says "filename" it saves to the
file, encrypted or not (this is not written).  It works on one
auth-sources spec at a time since only the first matching entry is
consulted, so it doesn't know if there are other specs.  It also doesn't
know if the file is encrypted or not--like I said I tried to keep
auth-source.el separate from the encryption/decryption layer.

Ted

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> It only creates if your sources include the Secrets API.  See
> `auth-source-create'.

Ah, right.

Any particular reason something like

(:source (:secrets default))

isn't part of the default?

> LMI> Even though a netrc file exists, shouldn't it save new passwords to the
> LMI> .gpg file?
>
> No, it will save to whatever is in the spec.  So if the spec says
> 'secrets then it saves to Secrets API (this is working thanks to help
> from Michael Albinus).

My main confusion here was that I thought the .gpg stuff was the same as
the Secrets stuff.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: "Format specifier doesn't match argument type" error message when exiting nnimap group

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Steinar Bang <sb@dod.no> writes:
>> Yes it did.  But the read count updated by the visit wasn't persisted.
>> A new `g' made the group show 1 unread article again.

> I got the opposite result -- `M-g' made the empty group say that it had
> 1 article. 

Depending on what you mean by "empty group", this is what I tried to say
I had as well.

> I've now fixed this.

Not for me.  A fresh `g' makes the 1 unread article count reappear on
the group.  This is on a git pull from this morning.

Re: "Format specifier doesn't match argument type" error message when exiting nnimap group

[Dan Christensen]

Steinar Bang <sb@dod.no> writes:

>>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:
>
>> Steinar Bang <sb@dod.no> writes:
>>> Yes it did.  But the read count updated by the visit wasn't persisted.
>>> A new `g' made the group show 1 unread article again.
>
>> I got the opposite result -- `M-g' made the empty group say that it had
>> 1 article. 
>
> Depending on what you mean by "empty group", this is what I tried to say
> I had as well.
>
>> I've now fixed this.
>
> Not for me.  A fresh `g' makes the 1 unread article count reappear on
> the group.  This is on a git pull from this morning.

My empty imap group (Drafts) still shows up with "*" for the unread count.

Dan

Re: Releasing the new nnimap on y'all soon

[Ted Zlatanov]

On Tue, 21 Sep 2010 23:34:19 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Any particular reason something like

LMI> (:source (:secrets default))

LMI> isn't part of the default?

It's not on all platforms because it depends on D-Bus and other
Gnome/KDE pieces and is not in XEmacs AFAIK.  We could activate it
conditionally when `secrets-enabled' is set, but that requires loading
the library and Emacs needs D-Bus support compiled in.  So I'm not sure.

Ted

Re: Releasing the new nnimap on y'all soon

[Michael Albinus]

Ted Zlatanov <tzz@lifelogs.com> writes:

> It's not on all platforms because it depends on D-Bus and other
> Gnome/KDE pieces and is not in XEmacs AFAIK.  We could activate it
> conditionally when `secrets-enabled' is set, but that requires loading
> the library and Emacs needs D-Bus support compiled in.  So I'm not sure.

You could check (featurep 'dbusbind) first, it is a compiled C module
when D-Bus is enabled.

> Ted

Best regards, Michael.

Re: "Format specifier doesn't match argument type" error message when exiting nnimap group

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

>> I've now fixed this.
>
> Not for me.  A fresh `g' makes the 1 unread article count reappear on
> the group.  This is on a git pull from this morning.

I'm unable to reproduce this -- I've tried creating empty groups with
Gmail and Dovecot.

Could you try pressing `g' and then try to find the corresponding entry
in the *nnimap ... * server buffer?  Look in the *imap log* buffer to
find the sequence number of the EXAMINE and FETCH commands on the group
that's displaying 1, and then find the data in the *nnimap ... * buffer.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: "Format specifier doesn't match argument type" error message when exiting nnimap group

[Lars Magne Ingebrigtsen]

Dan Christensen <jdc@uwo.ca> writes:

> My empty imap group (Drafts) still shows up with "*" for the unread count.

Could you try to do the same that I asked Steinar to do?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

>> It's not on all platforms because it depends on D-Bus and other
>> Gnome/KDE pieces and is not in XEmacs AFAIK.  We could activate it
>> conditionally when `secrets-enabled' is set, but that requires loading
>> the library and Emacs needs D-Bus support compiled in.  So I'm not sure.
>
> You could check (featurep 'dbusbind) first, it is a compiled C module
> when D-Bus is enabled.

Yes, that sounds like a good idea.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: "Format specifier doesn't match argument type" error message when exiting nnimap group

[Dan Christensen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Could you try pressing `g' and then try to find the corresponding entry
> in the *nnimap ... * server buffer?  Look in the *imap log* buffer to
> find the sequence number of the EXAMINE and FETCH commands on the group
> that's displaying 1, and then find the data in the *nnimap ... * buffer.

My nnimap+rocky:Drafts group shows * unread when Gnus first starts, and
this persists after hitting `g'.  Once I hit `M-g', the problem goes
away, and it doesn't reappear if I hit `g'.

The *nnimap...* buffer didn't seem to show enough history, so I can't
cut and paste from there, but I connected to the server manually
and repeated the commands:

1 EXAMINE "Drafts"
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 0 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1256067218] UIDs valid
* OK [UIDNEXT 13] Predicted next UID
1 OK [READ-ONLY] Select completed.
2 UID FETCH 1:* FLAGS
2 OK Fetch completed.

Hmm, why does it say "Read-only mailbox"?  Could that be related?

Dan

Re: "Format specifier doesn't match argument type" error message when exiting nnimap group

[Lars Magne Ingebrigtsen]

Dan Christensen <jdc@uwo.ca> writes:

> My nnimap+rocky:Drafts group shows * unread when Gnus first starts, and
> this persists after hitting `g'.  Once I hit `M-g', the problem goes
> away, and it doesn't reappear if I hit `g'.
>
> The *nnimap...* buffer didn't seem to show enough history, so I can't
> cut and paste from there, but I connected to the server manually
> and repeated the commands:
>
> 1 EXAMINE "Drafts"
> * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
> * OK [PERMANENTFLAGS ()] Read-only mailbox.
> * 0 EXISTS
> * 0 RECENT
> * OK [UIDVALIDITY 1256067218] UIDs valid
> * OK [UIDNEXT 13] Predicted next UID
> 1 OK [READ-ONLY] Select completed.
> 2 UID FETCH 1:* FLAGS
> 2 OK Fetch completed.
>
> Hmm, why does it say "Read-only mailbox"?  Could that be related?

No, that's what it says when you say EXAMINE.

Hm.  Looks OK to me.

What does

(gnus-active "nnimap+rocky:Drafts")

say when Gnus displays "*"?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: "Format specifier doesn't match argument type" error message when exiting nnimap group

[Dan Christensen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> What does
>
> (gnus-active "nnimap+rocky:Drafts")
>
> say when Gnus displays "*"?

It returns nil.

Dan

Re: "Format specifier doesn't match argument type" error message when exiting nnimap group

[Lars Magne Ingebrigtsen]

Dan Christensen <jdc@uwo.ca> writes:

>> (gnus-active "nnimap+rocky:Drafts")
>>
>> say when Gnus displays "*"?
>
> It returns nil.

That's at least consistent.  Hm...  Is the group on a level where it's
activated?  If not, then "*" is correct, isn't it?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: "Format specifier doesn't match argument type" error message when exiting nnimap group

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Could you try pressing `g' and then try to find the corresponding
> entry in the *nnimap ... * server buffer?  Look in the *imap log*
> buffer to find the sequence number of the EXAMINE and FETCH commands
> on the group that's displaying 1, and then find the data in the
> *nnimap ... * buffer.

Ok, I'll do that tomorrow when I have access to that machine again.
But meanwhile, did you see those `G E' results I posted earlier?
I think there is something messed up in the .newsrc.eld on that machine,
because I don't see the issue on a different gnus, like eg. this one.

Here are the `G E' for the same group on this gnus (which doesn't have
the problem):

("nnimap+privat:getmail" 2
 ((1 . 45))
 ((reply 28)
  (tick 25
        (30 . 31))
  (active 1 . 45)
  (seen
   (1 . 23)
   25
   (30 . 31)
   (39 . 40)
   (42 . 47)))
 "nnimap:privat"
 ((imap-status . "48 1 45")
  (uidvalidity . "1279388661")))

Hm... it does look similar, doesn't it?  Maybe that wasn't it after all?

Re: "Format specifier doesn't match argument type" error message when exiting nnimap group

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> Ok, I'll do that tomorrow when I have access to that machine again.
> But meanwhile, did you see those `G E' results I posted earlier?
> I think there is something messed up in the .newsrc.eld on that machine,
> because I don't see the issue on a different gnus, like eg. this one.

It's possible, but since Dan is seeing the same thing, I think it's an
nnimap problem.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: "Format specifier doesn't match argument type" error message when exiting nnimap group

[Dan Christensen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Dan Christensen <jdc@uwo.ca> writes:
>
>>> (gnus-active "nnimap+rocky:Drafts")
>>>
>>> say when Gnus displays "*"?
>>
>> It returns nil.
>
> That's at least consistent.  Hm...  Is the group on a level where it's
> activated?  If not, then "*" is correct, isn't it?

It's on level 2, as are most of the groups on that IMAP server, and it's
the only one that isn't activated.  (And the only one that is empty
now.  When I had another one empty, the same thing happened with that
one too.)  2 is my default level.

Dan

Re: "Format specifier doesn't match argument type" error message when exiting nnimap group

[Lars Magne Ingebrigtsen]

Dan Christensen <jdc@uwo.ca> writes:

> It's on level 2, as are most of the groups on that IMAP server, and it's
> the only one that isn't activated.  (And the only one that is empty
> now.  When I had another one empty, the same thing happened with that
> one too.)  2 is my default level.

This one was rather hard to track down.  I think I've now succeeded in
reproducing and fixing this, but I'm not quite sure.  Give it a whirl
and see what happens.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: "Format specifier doesn't match argument type" error message when exiting nnimap group

[Dan Christensen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Dan Christensen <jdc@uwo.ca> writes:
>
>> It's on level 2, as are most of the groups on that IMAP server, and it's
>> the only one that isn't activated.  (And the only one that is empty
>> now.  When I had another one empty, the same thing happened with that
>> one too.)  2 is my default level.
>
> This one was rather hard to track down.  I think I've now succeeded in
> reproducing and fixing this, but I'm not quite sure.  Give it a whirl
> and see what happens.

That group is activated properly now.  Thanks!

Dan

Re: "Format specifier doesn't match argument type" error message when exiting nnimap group

[Steinar Bang]

>>>>> Steinar Bang <sb@dod.no>:

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:
>> Could you try pressing `g' and then try to find the corresponding
>> entry in the *nnimap ... * server buffer?  Look in the *imap log*
>> buffer to find the sequence number of the EXAMINE and FETCH commands
>> on the group that's displaying 1, and then find the data in the
>> *nnimap ... * buffer.

> Ok, I'll do that tomorrow when I have access to that machine again.

Here are the results.  I've observed an interesting detail: the problem
folder "getmail" is EXAMINE'd twice during a `g' cycle.  See the excerpts
from *imap log* below:

A new `g' cycle is starting at 08:55.  It starts with the folder
"getmail" at 1424, _before_ the INBOX folder.

Then it selects the "getmail" folder again at the bottom (1442).

There is no "1424" or "1425" in the *nnimap ... * buffer.  It starts at
"1426" (ie. the EXAMINE of the INBOX).  I've included this buffer at the
bottom of this message.

08:54:42 1420 EXAMINE "getmail"
08:54:42 1421 UID FETCH 1:* FLAGS
08:54:42 1422 EXAMINE "gmail"
08:54:42 1423 UID FETCH 1:* FLAGS
08:55:23 1424 SELECT "getmail"
08:55:25 1425 UID STORE 46 +FLAGS.SILENT (\Seen)
08:55:38 1426 EXAMINE "INBOX"
08:55:38 1427 UID FETCH 538:* FLAGS
08:55:38 1428 EXAMINE "dod"
08:55:38 1429 UID FETCH 7006:* FLAGS
08:55:38 1430 EXAMINE "linux-hjelp"
08:55:38 1431 UID FETCH 989:* FLAGS
08:55:38 1432 EXAMINE "bristol"
08:55:38 1433 UID FETCH 1179:* FLAGS
08:55:38 1434 EXAMINE "dod-rt-viktig"
08:55:38 1435 UID FETCH 1:* FLAGS
08:55:38 1436 EXAMINE "dod-rt"
08:55:38 1437 UID FETCH 185:* FLAGS
08:55:38 1438 EXAMINE "doders"
08:55:38 1439 UID FETCH 2135:* FLAGS
08:55:38 1440 EXAMINE "nisjerdverger"
08:55:38 1441 UID FETCH 1782:* FLAGS
08:55:38 1442 EXAMINE "getmail"
08:55:38 1443 UID FETCH 1:* FLAGS
08:55:38 1444 EXAMINE "gmail"
08:55:38 1445 UID FETCH 1:* FLAGS


Here comes the *nnimap ...* buffer:
* OK [CLOSED] Previous mailbox closed.
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 582 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1221067842] UIDs valid
* OK [UIDNEXT 640] Predicted next UID
* OK [HIGHESTMODSEQ 7] Highest
1426 OK [READ-ONLY] Select completed.
* 515 FETCH (UID 539 FLAGS (\Seen))
* 516 FETCH (UID 540 FLAGS (\Seen))
* 517 FETCH (UID 541 FLAGS (\Seen))
* 518 FETCH (UID 542 FLAGS (\Seen))
* 519 FETCH (UID 543 FLAGS (\Seen))
* 520 FETCH (UID 544 FLAGS (\Seen))
* 521 FETCH (UID 545 FLAGS (\Seen))
* 522 FETCH (UID 546 FLAGS (\Seen))
* 523 FETCH (UID 547 FLAGS (\Seen))
* 524 FETCH (UID 548 FLAGS (\Seen))
* 525 FETCH (UID 549 FLAGS (\Seen))
* 526 FETCH (UID 550 FLAGS (\Seen))
* 527 FETCH (UID 551 FLAGS (\Flagged \Seen))
* 528 FETCH (UID 552 FLAGS (\Flagged \Seen))
* 529 FETCH (UID 553 FLAGS (\Flagged \Seen))
* 530 FETCH (UID 554 FLAGS (\Flagged \Seen))
* 531 FETCH (UID 555 FLAGS (\Flagged \Seen))
* 532 FETCH (UID 556 FLAGS (\Flagged \Seen))
* 533 FETCH (UID 557 FLAGS (\Flagged \Seen))
* 534 FETCH (UID 559 FLAGS (\Seen))
* 535 FETCH (UID 560 FLAGS (\Seen))
* 536 FETCH (UID 561 FLAGS (\Flagged \Seen))
* 537 FETCH (UID 562 FLAGS (\Flagged \Seen))
* 538 FETCH (UID 563 FLAGS (\Seen))
* 539 FETCH (UID 564 FLAGS (\Flagged \Seen))
* 540 FETCH (UID 565 FLAGS (\Flagged \Seen))
* 541 FETCH (UID 566 FLAGS (\Flagged \Seen))
* 542 FETCH (UID 567 FLAGS (\Flagged \Seen))
* 543 FETCH (UID 568 FLAGS (\Seen))
* 544 FETCH (UID 569 FLAGS (\Seen))
* 545 FETCH (UID 570 FLAGS (\Flagged \Seen))
* 546 FETCH (UID 571 FLAGS (\Seen))
* 547 FETCH (UID 572 FLAGS (\Flagged \Seen))
* 548 FETCH (UID 573 FLAGS (\Seen))
* 549 FETCH (UID 574 FLAGS (\Seen))
* 550 FETCH (UID 581 FLAGS (\Answered \Seen))
* 551 FETCH (UID 582 FLAGS (\Seen))
* 552 FETCH (UID 584 FLAGS (\Flagged \Seen))
* 553 FETCH (UID 585 FLAGS (\Flagged \Seen))
* 554 FETCH (UID 588 FLAGS (\Seen))
* 555 FETCH (UID 589 FLAGS (\Seen))
* 556 FETCH (UID 590 FLAGS (\Seen))
* 557 FETCH (UID 591 FLAGS (\Seen))
* 558 FETCH (UID 593 FLAGS (\Seen))
* 559 FETCH (UID 594 FLAGS (\Seen))
* 560 FETCH (UID 605 FLAGS (\Seen))
* 561 FETCH (UID 607 FLAGS (\Seen))
* 562 FETCH (UID 608 FLAGS (\Seen))
* 563 FETCH (UID 609 FLAGS (\Flagged \Seen))
* 564 FETCH (UID 610 FLAGS (\Seen))
* 565 FETCH (UID 611 FLAGS (\Seen))
* 566 FETCH (UID 612 FLAGS (\Seen))
* 567 FETCH (UID 615 FLAGS (\Seen))
* 568 FETCH (UID 616 FLAGS (\Seen))
* 569 FETCH (UID 617 FLAGS (\Seen))
* 570 FETCH (UID 618 FLAGS (\Seen))
* 571 FETCH (UID 620 FLAGS (\Seen))
* 572 FETCH (UID 622 FLAGS (\Seen))
* 573 FETCH (UID 623 FLAGS (\Seen))
* 574 FETCH (UID 624 FLAGS (\Seen))
* 575 FETCH (UID 625 FLAGS (\Seen))
* 576 FETCH (UID 629 FLAGS (\Seen))
* 577 FETCH (UID 632 FLAGS (\Seen))
* 578 FETCH (UID 633 FLAGS (\Seen))
* 579 FETCH (UID 634 FLAGS (\Seen))
* 580 FETCH (UID 635 FLAGS (\Seen))
* 581 FETCH (UID 637 FLAGS (\Flagged \Seen))
* 582 FETCH (UID 638 FLAGS (\Flagged \Seen))
1427 OK Fetch completed.
* OK [CLOSED] Previous mailbox closed.
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft gnus-forward $Forwarded)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 434 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1221068358] UIDs valid
* OK [UIDNEXT 7107] Predicted next UID
* OK [HIGHESTMODSEQ 19] Highest
1428 OK [READ-ONLY] Select completed.
* 337 FETCH (UID 7008 FLAGS (\Seen))
* 338 FETCH (UID 7009 FLAGS (\Answered \Seen))
* 339 FETCH (UID 7010 FLAGS (\Seen))
* 340 FETCH (UID 7011 FLAGS (\Seen))
* 341 FETCH (UID 7012 FLAGS (\Flagged \Seen))
* 342 FETCH (UID 7013 FLAGS (\Flagged \Seen))
* 343 FETCH (UID 7014 FLAGS (\Flagged \Seen))
* 344 FETCH (UID 7015 FLAGS (\Flagged \Seen))
* 345 FETCH (UID 7016 FLAGS (\Flagged \Seen))
* 346 FETCH (UID 7017 FLAGS (\Answered \Seen))
* 347 FETCH (UID 7018 FLAGS (\Flagged \Seen))
* 348 FETCH (UID 7019 FLAGS (\Seen))
* 349 FETCH (UID 7020 FLAGS (\Answered \Flagged \Seen))
* 350 FETCH (UID 7021 FLAGS (\Flagged \Seen))
* 351 FETCH (UID 7023 FLAGS (\Seen))
* 352 FETCH (UID 7024 FLAGS (\Flagged \Seen))
* 353 FETCH (UID 7025 FLAGS (\Seen))
* 354 FETCH (UID 7026 FLAGS (\Answered \Flagged \Seen))
* 355 FETCH (UID 7027 FLAGS (\Answered \Flagged \Seen))
* 356 FETCH (UID 7028 FLAGS (\Flagged \Seen))
* 357 FETCH (UID 7029 FLAGS (\Seen))
* 358 FETCH (UID 7030 FLAGS (\Seen))
* 359 FETCH (UID 7031 FLAGS (\Answered \Flagged \Seen))
* 360 FETCH (UID 7032 FLAGS (\Seen))
* 361 FETCH (UID 7033 FLAGS (\Seen))
* 362 FETCH (UID 7034 FLAGS (\Answered \Seen))
* 363 FETCH (UID 7035 FLAGS (\Seen))
* 364 FETCH (UID 7036 FLAGS (\Seen))
* 365 FETCH (UID 7037 FLAGS (\Flagged \Seen))
* 366 FETCH (UID 7038 FLAGS (\Flagged \Seen))
* 367 FETCH (UID 7039 FLAGS (\Flagged \Seen))
* 368 FETCH (UID 7040 FLAGS (\Seen))
* 369 FETCH (UID 7041 FLAGS (\Answered \Seen))
* 370 FETCH (UID 7042 FLAGS (\Seen))
* 371 FETCH (UID 7043 FLAGS (\Flagged \Seen))
* 372 FETCH (UID 7044 FLAGS (\Flagged \Seen))
* 373 FETCH (UID 7045 FLAGS (\Flagged \Seen))
* 374 FETCH (UID 7046 FLAGS (\Answered \Seen))
* 375 FETCH (UID 7047 FLAGS (\Seen))
* 376 FETCH (UID 7048 FLAGS (\Answered \Seen))
* 377 FETCH (UID 7049 FLAGS (\Seen))
* 378 FETCH (UID 7050 FLAGS (\Flagged \Seen))
* 379 FETCH (UID 7051 FLAGS (\Seen))
* 380 FETCH (UID 7052 FLAGS (\Answered \Seen))
* 381 FETCH (UID 7053 FLAGS (\Seen))
* 382 FETCH (UID 7054 FLAGS (\Seen))
* 383 FETCH (UID 7055 FLAGS (\Seen))
* 384 FETCH (UID 7056 FLAGS (\Flagged \Seen))
* 385 FETCH (UID 7057 FLAGS (\Flagged \Seen))
* 386 FETCH (UID 7058 FLAGS (\Flagged \Seen))
* 387 FETCH (UID 7059 FLAGS (\Seen))
* 388 FETCH (UID 7060 FLAGS (\Seen))
* 389 FETCH (UID 7061 FLAGS (\Seen))
* 390 FETCH (UID 7062 FLAGS (\Seen))
* 391 FETCH (UID 7063 FLAGS (\Seen))
* 392 FETCH (UID 7064 FLAGS (\Seen))
* 393 FETCH (UID 7065 FLAGS (\Seen))
* 394 FETCH (UID 7066 FLAGS (\Flagged \Seen))
* 395 FETCH (UID 7067 FLAGS (\Answered \Seen))
* 396 FETCH (UID 7068 FLAGS (\Answered \Seen))
* 397 FETCH (UID 7069 FLAGS (\Answered \Seen))
* 398 FETCH (UID 7070 FLAGS (\Seen))
* 399 FETCH (UID 7071 FLAGS (\Answered \Seen))
* 400 FETCH (UID 7072 FLAGS (\Seen))
* 401 FETCH (UID 7073 FLAGS (\Seen))
* 402 FETCH (UID 7074 FLAGS (\Seen))
* 403 FETCH (UID 7075 FLAGS (\Seen))
* 404 FETCH (UID 7076 FLAGS (\Flagged \Seen))
* 405 FETCH (UID 7077 FLAGS (\Flagged \Seen))
* 406 FETCH (UID 7078 FLAGS (\Answered \Flagged \Seen))
* 407 FETCH (UID 7079 FLAGS (\Answered \Flagged \Seen))
* 408 FETCH (UID 7080 FLAGS (\Flagged \Seen))
* 409 FETCH (UID 7081 FLAGS (\Flagged \Seen))
* 410 FETCH (UID 7082 FLAGS (\Seen))
* 411 FETCH (UID 7083 FLAGS (\Flagged \Seen))
* 412 FETCH (UID 7084 FLAGS (\Flagged \Seen))
* 413 FETCH (UID 7085 FLAGS (\Seen))
* 414 FETCH (UID 7086 FLAGS (\Seen))
* 415 FETCH (UID 7087 FLAGS (\Seen))
* 416 FETCH (UID 7088 FLAGS (\Seen))
* 417 FETCH (UID 7089 FLAGS (\Flagged \Seen))
* 418 FETCH (UID 7090 FLAGS (\Answered \Seen))
* 419 FETCH (UID 7091 FLAGS (\Seen))
* 420 FETCH (UID 7092 FLAGS (\Seen))
* 421 FETCH (UID 7093 FLAGS (\Answered \Seen))
* 422 FETCH (UID 7094 FLAGS (\Flagged \Seen))
* 423 FETCH (UID 7095 FLAGS (\Seen))
* 424 FETCH (UID 7096 FLAGS (\Flagged \Seen))
* 425 FETCH (UID 7097 FLAGS (\Seen))
* 426 FETCH (UID 7098 FLAGS (\Flagged \Seen))
* 427 FETCH (UID 7099 FLAGS (\Seen))
* 428 FETCH (UID 7100 FLAGS (\Answered \Seen))
* 429 FETCH (UID 7101 FLAGS (\Seen))
* 430 FETCH (UID 7102 FLAGS (\Answered \Seen))
* 431 FETCH (UID 7103 FLAGS (\Seen))
* 432 FETCH (UID 7104 FLAGS (\Seen))
* 433 FETCH (UID 7105 FLAGS (\Seen))
* 434 FETCH (UID 7106 FLAGS (\Seen))
1429 OK Fetch completed.
* OK [CLOSED] Previous mailbox closed.
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft gnus-forward)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 1084 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1221076285] UIDs valid
* OK [UIDNEXT 1090] Predicted next UID
* OK [HIGHESTMODSEQ 1] Highest
1430 OK [READ-ONLY] Select completed.
* 987 FETCH (UID 989 FLAGS (\Answered \Flagged \Seen))
* 988 FETCH (UID 990 FLAGS (\Flagged \Seen))
* 989 FETCH (UID 991 FLAGS (\Answered \Flagged \Seen))
* 990 FETCH (UID 992 FLAGS (\Answered \Flagged \Seen))
* 991 FETCH (UID 993 FLAGS (\Answered \Flagged \Seen))
* 992 FETCH (UID 994 FLAGS (\Answered \Flagged \Seen))
* 993 FETCH (UID 995 FLAGS (\Flagged \Seen))
* 994 FETCH (UID 996 FLAGS (\Answered \Flagged \Seen))
* 995 FETCH (UID 997 FLAGS (\Seen))
* 996 FETCH (UID 998 FLAGS (\Answered \Seen))
* 997 FETCH (UID 999 FLAGS (\Seen))
* 998 FETCH (UID 1000 FLAGS (\Seen))
* 999 FETCH (UID 1001 FLAGS (\Flagged \Seen))
* 1000 FETCH (UID 1002 FLAGS (\Flagged \Seen))
* 1001 FETCH (UID 1003 FLAGS (\Flagged \Seen))
* 1002 FETCH (UID 1004 FLAGS (\Answered \Flagged \Seen))
* 1003 FETCH (UID 1005 FLAGS (\Flagged \Seen))
* 1004 FETCH (UID 1006 FLAGS (\Answered \Flagged \Seen))
* 1005 FETCH (UID 1007 FLAGS (\Answered \Flagged \Seen))
* 1006 FETCH (UID 1008 FLAGS (\Flagged \Seen))
* 1007 FETCH (UID 1009 FLAGS (\Answered \Flagged \Seen))
* 1008 FETCH (UID 1010 FLAGS (\Flagged \Seen))
* 1009 FETCH (UID 1012 FLAGS (\Answered \Flagged \Seen))
* 1010 FETCH (UID 1013 FLAGS (\Flagged \Seen))
* 1011 FETCH (UID 1014 FLAGS (\Answered \Flagged \Seen))
* 1012 FETCH (UID 1015 FLAGS (\Flagged \Seen))
* 1013 FETCH (UID 1016 FLAGS (\Answered \Flagged \Seen))
* 1014 FETCH (UID 1017 FLAGS (\Flagged \Seen))
* 1015 FETCH (UID 1018 FLAGS (\Answered \Flagged \Seen))
* 1016 FETCH (UID 1019 FLAGS (\Flagged \Seen))
* 1017 FETCH (UID 1020 FLAGS (\Answered \Flagged \Seen))
* 1018 FETCH (UID 1021 FLAGS (\Flagged \Seen))
* 1019 FETCH (UID 1022 FLAGS (\Answered \Flagged \Seen))
* 1020 FETCH (UID 1023 FLAGS (\Flagged \Seen))
* 1021 FETCH (UID 1024 FLAGS (\Flagged \Seen))
* 1022 FETCH (UID 1025 FLAGS (\Answered \Flagged \Seen))
* 1023 FETCH (UID 1026 FLAGS (\Answered \Flagged \Seen))
* 1024 FETCH (UID 1027 FLAGS (\Flagged \Seen))
* 1025 FETCH (UID 1029 FLAGS (\Answered \Flagged \Seen))
* 1026 FETCH (UID 1031 FLAGS (\Flagged \Seen))
* 1027 FETCH (UID 1032 FLAGS (\Answered \Flagged \Seen))
* 1028 FETCH (UID 1033 FLAGS (\Answered \Flagged \Seen))
* 1029 FETCH (UID 1034 FLAGS (\Flagged \Seen))
* 1030 FETCH (UID 1035 FLAGS (\Answered \Flagged \Seen))
* 1031 FETCH (UID 1036 FLAGS (\Flagged \Seen))
* 1032 FETCH (UID 1037 FLAGS (\Answered \Seen))
* 1033 FETCH (UID 1038 FLAGS (\Seen))
* 1034 FETCH (UID 1039 FLAGS (\Answered \Seen))
* 1035 FETCH (UID 1040 FLAGS (\Answered \Seen))
* 1036 FETCH (UID 1041 FLAGS (\Seen))
* 1037 FETCH (UID 1042 FLAGS (\Seen))
* 1038 FETCH (UID 1043 FLAGS (\Answered \Seen))
* 1039 FETCH (UID 1044 FLAGS (\Answered \Seen))
* 1040 FETCH (UID 1045 FLAGS (\Answered \Seen))
* 1041 FETCH (UID 1046 FLAGS (\Seen))
* 1042 FETCH (UID 1047 FLAGS (\Seen))
* 1043 FETCH (UID 1048 FLAGS (\Answered \Seen))
* 1044 FETCH (UID 1049 FLAGS (\Seen))
* 1045 FETCH (UID 1050 FLAGS (\Answered \Seen))
* 1046 FETCH (UID 1051 FLAGS (\Seen))
* 1047 FETCH (UID 1052 FLAGS (\Answered \Seen))
* 1048 FETCH (UID 1053 FLAGS (\Flagged \Seen))
* 1049 FETCH (UID 1054 FLAGS (\Answered \Flagged \Seen))
* 1050 FETCH (UID 1055 FLAGS (\Answered \Flagged \Seen))
* 1051 FETCH (UID 1056 FLAGS (\Answered \Seen))
* 1052 FETCH (UID 1057 FLAGS (\Seen))
* 1053 FETCH (UID 1058 FLAGS (\Answered \Seen))
* 1054 FETCH (UID 1059 FLAGS (\Seen))
* 1055 FETCH (UID 1060 FLAGS (\Seen))
* 1056 FETCH (UID 1061 FLAGS (\Seen))
* 1057 FETCH (UID 1062 FLAGS (\Answered \Flagged \Seen))
* 1058 FETCH (UID 1063 FLAGS (\Answered \Flagged \Seen))
* 1059 FETCH (UID 1064 FLAGS (\Answered \Flagged \Seen))
* 1060 FETCH (UID 1065 FLAGS (\Answered \Flagged \Seen))
* 1061 FETCH (UID 1066 FLAGS (\Answered \Seen))
* 1062 FETCH (UID 1067 FLAGS (\Answered \Seen))
* 1063 FETCH (UID 1068 FLAGS (\Seen))
* 1064 FETCH (UID 1069 FLAGS (\Seen))
* 1065 FETCH (UID 1070 FLAGS (\Flagged \Seen))
* 1066 FETCH (UID 1071 FLAGS (\Answered \Flagged \Seen))
* 1067 FETCH (UID 1072 FLAGS (\Flagged \Seen))
* 1068 FETCH (UID 1073 FLAGS (\Answered \Flagged \Seen))
* 1069 FETCH (UID 1074 FLAGS (\Flagged \Seen))
* 1070 FETCH (UID 1075 FLAGS (\Answered \Flagged \Seen))
* 1071 FETCH (UID 1076 FLAGS (\Flagged \Seen))
* 1072 FETCH (UID 1077 FLAGS (\Flagged \Seen))
* 1073 FETCH (UID 1078 FLAGS (\Answered \Flagged \Seen))
* 1074 FETCH (UID 1079 FLAGS (\Flagged \Seen))
* 1075 FETCH (UID 1080 FLAGS (\Flagged \Seen))
* 1076 FETCH (UID 1081 FLAGS (\Answered \Flagged \Seen))
* 1077 FETCH (UID 1082 FLAGS (\Flagged \Seen))
* 1078 FETCH (UID 1083 FLAGS (\Answered \Flagged \Seen))
* 1079 FETCH (UID 1084 FLAGS (\Flagged \Seen))
* 1080 FETCH (UID 1085 FLAGS (\Answered \Flagged \Seen))
* 1081 FETCH (UID 1086 FLAGS (\Answered \Seen))
* 1082 FETCH (UID 1087 FLAGS (\Seen))
* 1083 FETCH (UID 1088 FLAGS (\Flagged \Seen))
* 1084 FETCH (UID 1089 FLAGS (\Flagged \Seen))
1431 OK Fetch completed.
* OK [CLOSED] Previous mailbox closed.
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft gnus-forward gnus-dormant)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 1271 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1221068129] UIDs valid
* OK [UIDNEXT 1280] Predicted next UID
* OK [HIGHESTMODSEQ 1] Highest
1432 OK [READ-ONLY] Select completed.
* 1171 FETCH (UID 1179 FLAGS (\Seen))
* 1172 FETCH (UID 1180 FLAGS (\Seen))
* 1173 FETCH (UID 1181 FLAGS (\Seen))
* 1174 FETCH (UID 1182 FLAGS (\Answered \Seen))
* 1175 FETCH (UID 1183 FLAGS (\Seen))
* 1176 FETCH (UID 1184 FLAGS (\Seen))
* 1177 FETCH (UID 1185 FLAGS (\Seen))
* 1178 FETCH (UID 1186 FLAGS (\Seen))
* 1179 FETCH (UID 1187 FLAGS (\Seen))
* 1180 FETCH (UID 1188 FLAGS (\Seen))
* 1181 FETCH (UID 1189 FLAGS (\Seen))
* 1182 FETCH (UID 1190 FLAGS (\Answered \Seen))
* 1183 FETCH (UID 1191 FLAGS (\Seen))
* 1184 FETCH (UID 1192 FLAGS (\Seen))
* 1185 FETCH (UID 1193 FLAGS (\Seen))
* 1186 FETCH (UID 1194 FLAGS (\Seen))
* 1187 FETCH (UID 1195 FLAGS (\Answered \Seen))
* 1188 FETCH (UID 1196 FLAGS (\Seen))
* 1189 FETCH (UID 1197 FLAGS (\Seen))
* 1190 FETCH (UID 1198 FLAGS (\Seen))
* 1191 FETCH (UID 1199 FLAGS (\Seen))
* 1192 FETCH (UID 1200 FLAGS (\Seen))
* 1193 FETCH (UID 1201 FLAGS (\Seen))
* 1194 FETCH (UID 1202 FLAGS (\Answered \Seen))
* 1195 FETCH (UID 1203 FLAGS (\Seen))
* 1196 FETCH (UID 1204 FLAGS (\Answered \Seen))
* 1197 FETCH (UID 1205 FLAGS (\Seen))
* 1198 FETCH (UID 1206 FLAGS (\Seen))
* 1199 FETCH (UID 1207 FLAGS (\Seen))
* 1200 FETCH (UID 1208 FLAGS (\Seen))
* 1201 FETCH (UID 1209 FLAGS (\Seen))
* 1202 FETCH (UID 1210 FLAGS (\Seen))
* 1203 FETCH (UID 1211 FLAGS (\Seen))
* 1204 FETCH (UID 1212 FLAGS (\Seen))
* 1205 FETCH (UID 1213 FLAGS (\Seen))
* 1206 FETCH (UID 1214 FLAGS (\Answered \Seen))
* 1207 FETCH (UID 1215 FLAGS (\Seen))
* 1208 FETCH (UID 1216 FLAGS (\Seen))
* 1209 FETCH (UID 1217 FLAGS (\Seen))
* 1210 FETCH (UID 1218 FLAGS (\Answered \Seen))
* 1211 FETCH (UID 1219 FLAGS (\Seen))
* 1212 FETCH (UID 1220 FLAGS (\Seen))
* 1213 FETCH (UID 1221 FLAGS (\Seen))
* 1214 FETCH (UID 1222 FLAGS (\Seen))
* 1215 FETCH (UID 1223 FLAGS (\Seen))
* 1216 FETCH (UID 1224 FLAGS (\Answered \Seen))
* 1217 FETCH (UID 1225 FLAGS (\Seen))
* 1218 FETCH (UID 1226 FLAGS (\Flagged \Seen))
* 1219 FETCH (UID 1227 FLAGS (\Seen))
* 1220 FETCH (UID 1228 FLAGS (\Seen))
* 1221 FETCH (UID 1229 FLAGS (\Seen))
* 1222 FETCH (UID 1230 FLAGS (\Answered \Seen))
* 1223 FETCH (UID 1231 FLAGS (\Answered \Seen))
* 1224 FETCH (UID 1232 FLAGS (\Seen))
* 1225 FETCH (UID 1233 FLAGS (\Seen))
* 1226 FETCH (UID 1234 FLAGS (\Seen))
* 1227 FETCH (UID 1235 FLAGS (\Seen))
* 1228 FETCH (UID 1236 FLAGS (\Answered \Seen))
* 1229 FETCH (UID 1237 FLAGS (\Seen))
* 1230 FETCH (UID 1238 FLAGS (\Seen))
* 1231 FETCH (UID 1239 FLAGS (\Seen))
* 1232 FETCH (UID 1240 FLAGS (\Answered \Flagged \Seen gnus-dormant))
* 1233 FETCH (UID 1241 FLAGS (\Answered \Seen))
* 1234 FETCH (UID 1242 FLAGS (\Answered \Seen))
* 1235 FETCH (UID 1243 FLAGS (\Seen))
* 1236 FETCH (UID 1244 FLAGS (\Seen))
* 1237 FETCH (UID 1245 FLAGS (\Seen))
* 1238 FETCH (UID 1246 FLAGS (\Seen))
* 1239 FETCH (UID 1247 FLAGS (\Seen))
* 1240 FETCH (UID 1248 FLAGS (\Seen))
* 1241 FETCH (UID 1249 FLAGS (\Flagged \Seen))
* 1242 FETCH (UID 1250 FLAGS (\Answered \Seen))
* 1243 FETCH (UID 1251 FLAGS (\Seen))
* 1244 FETCH (UID 1252 FLAGS (\Seen))
* 1245 FETCH (UID 1253 FLAGS (\Seen))
* 1246 FETCH (UID 1254 FLAGS (\Seen))
* 1247 FETCH (UID 1255 FLAGS (\Flagged \Seen))
* 1248 FETCH (UID 1256 FLAGS (\Answered \Flagged \Seen))
* 1249 FETCH (UID 1257 FLAGS (\Answered \Flagged \Seen))
* 1250 FETCH (UID 1258 FLAGS (\Answered \Flagged \Seen))
* 1251 FETCH (UID 1259 FLAGS (\Flagged \Seen))
* 1252 FETCH (UID 1260 FLAGS (\Flagged \Seen))
* 1253 FETCH (UID 1261 FLAGS (\Answered \Flagged \Seen))
* 1254 FETCH (UID 1262 FLAGS (\Flagged \Seen))
* 1255 FETCH (UID 1263 FLAGS (\Answered \Flagged \Seen))
* 1256 FETCH (UID 1264 FLAGS (\Flagged \Seen))
* 1257 FETCH (UID 1265 FLAGS (\Answered \Flagged \Seen))
* 1258 FETCH (UID 1266 FLAGS (\Answered \Flagged \Seen))
* 1259 FETCH (UID 1267 FLAGS (\Answered \Seen))
* 1260 FETCH (UID 1268 FLAGS (\Seen))
* 1261 FETCH (UID 1269 FLAGS (\Seen))
* 1262 FETCH (UID 1270 FLAGS (\Seen))
* 1263 FETCH (UID 1271 FLAGS (\Seen))
* 1264 FETCH (UID 1272 FLAGS (\Seen))
* 1265 FETCH (UID 1273 FLAGS (\Answered \Seen))
* 1266 FETCH (UID 1274 FLAGS (\Seen))
* 1267 FETCH (UID 1275 FLAGS (\Answered \Seen))
* 1268 FETCH (UID 1276 FLAGS (\Seen))
* 1269 FETCH (UID 1277 FLAGS (\Seen))
* 1270 FETCH (UID 1278 FLAGS (\Seen))
* 1271 FETCH (UID 1279 FLAGS (\Seen))
1433 OK Fetch completed.
* OK [CLOSED] Previous mailbox closed.
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 3 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1221068971] UIDs valid
* OK [UIDNEXT 4] Predicted next UID
* OK [HIGHESTMODSEQ 1] Highest
1434 OK [READ-ONLY] Select completed.
* 1 FETCH (UID 1 FLAGS (\Flagged \Seen))
* 2 FETCH (UID 2 FLAGS (\Flagged \Seen))
* 3 FETCH (UID 3 FLAGS (\Flagged \Seen))
1435 OK Fetch completed.
* OK [CLOSED] Previous mailbox closed.
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 285 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1221068928] UIDs valid
* OK [UIDNEXT 286] Predicted next UID
* OK [HIGHESTMODSEQ 1] Highest
1436 OK [READ-ONLY] Select completed.
* 185 FETCH (UID 185 FLAGS (\Seen))
* 186 FETCH (UID 186 FLAGS (\Seen))
* 187 FETCH (UID 187 FLAGS (\Seen))
* 188 FETCH (UID 188 FLAGS (\Seen))
* 189 FETCH (UID 189 FLAGS (\Seen))
* 190 FETCH (UID 190 FLAGS (\Seen))
* 191 FETCH (UID 191 FLAGS (\Seen))
* 192 FETCH (UID 192 FLAGS (\Seen))
* 193 FETCH (UID 193 FLAGS (\Seen))
* 194 FETCH (UID 194 FLAGS (\Seen))
* 195 FETCH (UID 195 FLAGS (\Seen))
* 196 FETCH (UID 196 FLAGS (\Seen))
* 197 FETCH (UID 197 FLAGS (\Seen))
* 198 FETCH (UID 198 FLAGS (\Seen))
* 199 FETCH (UID 199 FLAGS (\Seen))
* 200 FETCH (UID 200 FLAGS (\Seen))
* 201 FETCH (UID 201 FLAGS (\Seen))
* 202 FETCH (UID 202 FLAGS (\Seen))
* 203 FETCH (UID 203 FLAGS (\Seen))
* 204 FETCH (UID 204 FLAGS (\Seen))
* 205 FETCH (UID 205 FLAGS (\Seen))
* 206 FETCH (UID 206 FLAGS (\Answered \Seen))
* 207 FETCH (UID 207 FLAGS (\Seen))
* 208 FETCH (UID 208 FLAGS (\Seen))
* 209 FETCH (UID 209 FLAGS (\Seen))
* 210 FETCH (UID 210 FLAGS (\Seen))
* 211 FETCH (UID 211 FLAGS (\Seen))
* 212 FETCH (UID 212 FLAGS (\Seen))
* 213 FETCH (UID 213 FLAGS (\Seen))
* 214 FETCH (UID 214 FLAGS (\Seen))
* 215 FETCH (UID 215 FLAGS (\Seen))
* 216 FETCH (UID 216 FLAGS (\Seen))
* 217 FETCH (UID 217 FLAGS (\Seen))
* 218 FETCH (UID 218 FLAGS (\Seen))
* 219 FETCH (UID 219 FLAGS (\Seen))
* 220 FETCH (UID 220 FLAGS (\Seen))
* 221 FETCH (UID 221 FLAGS (\Seen))
* 222 FETCH (UID 222 FLAGS (\Seen))
* 223 FETCH (UID 223 FLAGS (\Seen))
* 224 FETCH (UID 224 FLAGS (\Seen))
* 225 FETCH (UID 225 FLAGS (\Seen))
* 226 FETCH (UID 226 FLAGS (\Seen))
* 227 FETCH (UID 227 FLAGS (\Seen))
* 228 FETCH (UID 228 FLAGS (\Seen))
* 229 FETCH (UID 229 FLAGS (\Seen))
* 230 FETCH (UID 230 FLAGS (\Seen))
* 231 FETCH (UID 231 FLAGS (\Seen))
* 232 FETCH (UID 232 FLAGS (\Seen))
* 233 FETCH (UID 233 FLAGS (\Seen))
* 234 FETCH (UID 234 FLAGS (\Seen))
* 235 FETCH (UID 235 FLAGS (\Seen))
* 236 FETCH (UID 236 FLAGS (\Seen))
* 237 FETCH (UID 237 FLAGS (\Seen))
* 238 FETCH (UID 238 FLAGS (\Seen))
* 239 FETCH (UID 239 FLAGS (\Seen))
* 240 FETCH (UID 240 FLAGS (\Seen))
* 241 FETCH (UID 241 FLAGS (\Seen))
* 242 FETCH (UID 242 FLAGS (\Seen))
* 243 FETCH (UID 243 FLAGS (\Seen))
* 244 FETCH (UID 244 FLAGS (\Seen))
* 245 FETCH (UID 245 FLAGS (\Seen))
* 246 FETCH (UID 246 FLAGS (\Seen))
* 247 FETCH (UID 247 FLAGS (\Seen))
* 248 FETCH (UID 248 FLAGS (\Seen))
* 249 FETCH (UID 249 FLAGS (\Seen))
* 250 FETCH (UID 250 FLAGS (\Seen))
* 251 FETCH (UID 251 FLAGS (\Seen))
* 252 FETCH (UID 252 FLAGS (\Seen))
* 253 FETCH (UID 253 FLAGS (\Seen))
* 254 FETCH (UID 254 FLAGS (\Seen))
* 255 FETCH (UID 255 FLAGS (\Seen))
* 256 FETCH (UID 256 FLAGS (\Seen))
* 257 FETCH (UID 257 FLAGS (\Seen))
* 258 FETCH (UID 258 FLAGS (\Seen))
* 259 FETCH (UID 259 FLAGS (\Seen))
* 260 FETCH (UID 260 FLAGS (\Seen))
* 261 FETCH (UID 261 FLAGS (\Seen))
* 262 FETCH (UID 262 FLAGS (\Seen))
* 263 FETCH (UID 263 FLAGS (\Seen))
* 264 FETCH (UID 264 FLAGS (\Seen))
* 265 FETCH (UID 265 FLAGS (\Seen))
* 266 FETCH (UID 266 FLAGS (\Seen))
* 267 FETCH (UID 267 FLAGS (\Seen))
* 268 FETCH (UID 268 FLAGS (\Answered \Seen))
* 269 FETCH (UID 269 FLAGS (\Seen))
* 270 FETCH (UID 270 FLAGS (\Answered \Seen))
* 271 FETCH (UID 271 FLAGS (\Seen))
* 272 FETCH (UID 272 FLAGS (\Seen))
* 273 FETCH (UID 273 FLAGS (\Seen))
* 274 FETCH (UID 274 FLAGS (\Seen))
* 275 FETCH (UID 275 FLAGS (\Seen))
* 276 FETCH (UID 276 FLAGS (\Flagged \Seen))
* 277 FETCH (UID 277 FLAGS (\Seen))
* 278 FETCH (UID 278 FLAGS (\Seen))
* 279 FETCH (UID 279 FLAGS (\Seen))
* 280 FETCH (UID 280 FLAGS (\Seen))
* 281 FETCH (UID 281 FLAGS (\Seen))
* 282 FETCH (UID 282 FLAGS (\Seen))
* 283 FETCH (UID 283 FLAGS (\Seen))
* 284 FETCH (UID 284 FLAGS (\Seen))
* 285 FETCH (UID 285 FLAGS (\Seen))
1437 OK Fetch completed.
* OK [CLOSED] Previous mailbox closed.
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 2235 EXISTS
* 1 RECENT
* OK [UNSEEN 507] First unseen.
* OK [UIDVALIDITY 1221075897] UIDs valid
* OK [UIDNEXT 2236] Predicted next UID
* OK [HIGHESTMODSEQ 1] Highest
1438 OK [READ-ONLY] Select completed.
* 2135 FETCH (UID 2135 FLAGS ())
* 2136 FETCH (UID 2136 FLAGS ())
* 2137 FETCH (UID 2137 FLAGS ())
* 2138 FETCH (UID 2138 FLAGS ())
* 2139 FETCH (UID 2139 FLAGS ())
* 2140 FETCH (UID 2140 FLAGS ())
* 2141 FETCH (UID 2141 FLAGS ())
* 2142 FETCH (UID 2142 FLAGS ())
* 2143 FETCH (UID 2143 FLAGS ())
* 2144 FETCH (UID 2144 FLAGS ())
* 2145 FETCH (UID 2145 FLAGS ())
* 2146 FETCH (UID 2146 FLAGS ())
* 2147 FETCH (UID 2147 FLAGS ())
* 2148 FETCH (UID 2148 FLAGS ())
* 2149 FETCH (UID 2149 FLAGS ())
* 2150 FETCH (UID 2150 FLAGS ())
* 2151 FETCH (UID 2151 FLAGS ())
* 2152 FETCH (UID 2152 FLAGS ())
* 2153 FETCH (UID 2153 FLAGS ())
* 2154 FETCH (UID 2154 FLAGS ())
* 2155 FETCH (UID 2155 FLAGS ())
* 2156 FETCH (UID 2156 FLAGS ())
* 2157 FETCH (UID 2157 FLAGS ())
* 2158 FETCH (UID 2158 FLAGS ())
* 2159 FETCH (UID 2159 FLAGS ())
* 2160 FETCH (UID 2160 FLAGS ())
* 2161 FETCH (UID 2161 FLAGS ())
* 2162 FETCH (UID 2162 FLAGS ())
* 2163 FETCH (UID 2163 FLAGS ())
* 2164 FETCH (UID 2164 FLAGS ())
* 2165 FETCH (UID 2165 FLAGS ())
* 2166 FETCH (UID 2166 FLAGS ())
* 2167 FETCH (UID 2167 FLAGS ())
* 2168 FETCH (UID 2168 FLAGS ())
* 2169 FETCH (UID 2169 FLAGS ())
* 2170 FETCH (UID 2170 FLAGS ())
* 2171 FETCH (UID 2171 FLAGS ())
* 2172 FETCH (UID 2172 FLAGS ())
* 2173 FETCH (UID 2173 FLAGS ())
* 2174 FETCH (UID 2174 FLAGS ())
* 2175 FETCH (UID 2175 FLAGS ())
* 2176 FETCH (UID 2176 FLAGS ())
* 2177 FETCH (UID 2177 FLAGS ())
* 2178 FETCH (UID 2178 FLAGS ())
* 2179 FETCH (UID 2179 FLAGS ())
* 2180 FETCH (UID 2180 FLAGS ())
* 2181 FETCH (UID 2181 FLAGS ())
* 2182 FETCH (UID 2182 FLAGS ())
* 2183 FETCH (UID 2183 FLAGS ())
* 2184 FETCH (UID 2184 FLAGS ())
* 2185 FETCH (UID 2185 FLAGS ())
* 2186 FETCH (UID 2186 FLAGS ())
* 2187 FETCH (UID 2187 FLAGS ())
* 2188 FETCH (UID 2188 FLAGS ())
* 2189 FETCH (UID 2189 FLAGS ())
* 2190 FETCH (UID 2190 FLAGS ())
* 2191 FETCH (UID 2191 FLAGS ())
* 2192 FETCH (UID 2192 FLAGS ())
* 2193 FETCH (UID 2193 FLAGS ())
* 2194 FETCH (UID 2194 FLAGS ())
* 2195 FETCH (UID 2195 FLAGS ())
* 2196 FETCH (UID 2196 FLAGS ())
* 2197 FETCH (UID 2197 FLAGS ())
* 2198 FETCH (UID 2198 FLAGS ())
* 2199 FETCH (UID 2199 FLAGS ())
* 2200 FETCH (UID 2200 FLAGS ())
* 2201 FETCH (UID 2201 FLAGS ())
* 2202 FETCH (UID 2202 FLAGS ())
* 2203 FETCH (UID 2203 FLAGS ())
* 2204 FETCH (UID 2204 FLAGS ())
* 2205 FETCH (UID 2205 FLAGS ())
* 2206 FETCH (UID 2206 FLAGS ())
* 2207 FETCH (UID 2207 FLAGS ())
* 2208 FETCH (UID 2208 FLAGS ())
* 2209 FETCH (UID 2209 FLAGS ())
* 2210 FETCH (UID 2210 FLAGS ())
* 2211 FETCH (UID 2211 FLAGS ())
* 2212 FETCH (UID 2212 FLAGS ())
* 2213 FETCH (UID 2213 FLAGS ())
* 2214 FETCH (UID 2214 FLAGS ())
* 2215 FETCH (UID 2215 FLAGS ())
* 2216 FETCH (UID 2216 FLAGS ())
* 2217 FETCH (UID 2217 FLAGS ())
* 2218 FETCH (UID 2218 FLAGS ())
* 2219 FETCH (UID 2219 FLAGS ())
* 2220 FETCH (UID 2220 FLAGS ())
* 2221 FETCH (UID 2221 FLAGS ())
* 2222 FETCH (UID 2222 FLAGS ())
* 2223 FETCH (UID 2223 FLAGS ())
* 2224 FETCH (UID 2224 FLAGS ())
* 2225 FETCH (UID 2225 FLAGS ())
* 2226 FETCH (UID 2226 FLAGS ())
* 2227 FETCH (UID 2227 FLAGS ())
* 2228 FETCH (UID 2228 FLAGS ())
* 2229 FETCH (UID 2229 FLAGS ())
* 2230 FETCH (UID 2230 FLAGS ())
* 2231 FETCH (UID 2231 FLAGS ())
* 2232 FETCH (UID 2232 FLAGS ())
* 2233 FETCH (UID 2233 FLAGS ())
* 2234 FETCH (UID 2234 FLAGS ())
* 2235 FETCH (UID 2235 FLAGS (\Recent))
1439 OK Fetch completed.
* OK [CLOSED] Previous mailbox closed.
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft gnus-forward gnus-dormant)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 1879 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1221076465] UIDs valid
* OK [UIDNEXT 1883] Predicted next UID
* OK [HIGHESTMODSEQ 1] Highest
1440 OK [READ-ONLY] Select completed.
* 1779 FETCH (UID 1782 FLAGS (\Flagged \Seen))
* 1780 FETCH (UID 1783 FLAGS (\Flagged \Seen))
* 1781 FETCH (UID 1784 FLAGS (\Flagged \Seen))
* 1782 FETCH (UID 1785 FLAGS (\Flagged \Seen))
* 1783 FETCH (UID 1786 FLAGS (\Flagged \Seen))
* 1784 FETCH (UID 1787 FLAGS (\Flagged \Seen))
* 1785 FETCH (UID 1788 FLAGS (\Answered \Flagged \Seen))
* 1786 FETCH (UID 1789 FLAGS (\Flagged \Seen))
* 1787 FETCH (UID 1790 FLAGS (\Flagged \Seen))
* 1788 FETCH (UID 1791 FLAGS (\Flagged \Seen))
* 1789 FETCH (UID 1792 FLAGS (\Flagged \Seen))
* 1790 FETCH (UID 1793 FLAGS (\Flagged \Seen))
* 1791 FETCH (UID 1794 FLAGS (\Flagged \Seen))
* 1792 FETCH (UID 1795 FLAGS (\Flagged \Seen))
* 1793 FETCH (UID 1796 FLAGS (\Flagged \Seen gnus-dormant))
* 1794 FETCH (UID 1797 FLAGS (\Answered \Seen))
* 1795 FETCH (UID 1798 FLAGS (\Seen))
* 1796 FETCH (UID 1799 FLAGS (\Seen))
* 1797 FETCH (UID 1800 FLAGS (\Seen))
* 1798 FETCH (UID 1801 FLAGS (\Seen))
* 1799 FETCH (UID 1802 FLAGS (\Seen))
* 1800 FETCH (UID 1803 FLAGS (\Seen))
* 1801 FETCH (UID 1804 FLAGS (\Seen))
* 1802 FETCH (UID 1805 FLAGS (\Seen))
* 1803 FETCH (UID 1806 FLAGS (\Seen))
* 1804 FETCH (UID 1807 FLAGS (\Seen))
* 1805 FETCH (UID 1808 FLAGS (\Seen))
* 1806 FETCH (UID 1809 FLAGS (\Seen))
* 1807 FETCH (UID 1810 FLAGS (\Seen))
* 1808 FETCH (UID 1811 FLAGS (\Seen))
* 1809 FETCH (UID 1812 FLAGS (\Seen))
* 1810 FETCH (UID 1813 FLAGS (\Seen))
* 1811 FETCH (UID 1814 FLAGS (\Seen))
* 1812 FETCH (UID 1815 FLAGS (\Seen))
* 1813 FETCH (UID 1816 FLAGS (\Seen))
* 1814 FETCH (UID 1817 FLAGS (\Seen))
* 1815 FETCH (UID 1818 FLAGS (\Seen))
* 1816 FETCH (UID 1819 FLAGS (\Seen))
* 1817 FETCH (UID 1820 FLAGS (\Seen))
* 1818 FETCH (UID 1821 FLAGS (\Seen))
* 1819 FETCH (UID 1822 FLAGS (\Answered \Seen))
* 1820 FETCH (UID 1823 FLAGS (\Seen))
* 1821 FETCH (UID 1824 FLAGS (\Seen))
* 1822 FETCH (UID 1825 FLAGS (\Answered \Seen))
* 1823 FETCH (UID 1826 FLAGS (\Flagged \Seen))
* 1824 FETCH (UID 1827 FLAGS (\Flagged \Seen))
* 1825 FETCH (UID 1828 FLAGS (\Flagged \Seen))
* 1826 FETCH (UID 1829 FLAGS (\Flagged \Seen))
* 1827 FETCH (UID 1830 FLAGS (\Answered \Seen))
* 1828 FETCH (UID 1831 FLAGS (\Seen))
* 1829 FETCH (UID 1832 FLAGS (\Answered \Seen))
* 1830 FETCH (UID 1833 FLAGS (\Seen))
* 1831 FETCH (UID 1834 FLAGS (\Seen))
* 1832 FETCH (UID 1835 FLAGS (\Seen))
* 1833 FETCH (UID 1836 FLAGS (\Seen))
* 1834 FETCH (UID 1837 FLAGS (\Seen))
* 1835 FETCH (UID 1838 FLAGS (\Seen))
* 1836 FETCH (UID 1839 FLAGS (\Seen))
* 1837 FETCH (UID 1840 FLAGS (\Seen))
* 1838 FETCH (UID 1841 FLAGS (\Seen))
* 1839 FETCH (UID 1842 FLAGS (\Seen))
* 1840 FETCH (UID 1843 FLAGS (\Seen))
* 1841 FETCH (UID 1844 FLAGS (\Seen))
* 1842 FETCH (UID 1845 FLAGS (\Seen))
* 1843 FETCH (UID 1846 FLAGS (\Seen))
* 1844 FETCH (UID 1847 FLAGS (\Seen))
* 1845 FETCH (UID 1848 FLAGS (\Seen))
* 1846 FETCH (UID 1849 FLAGS (\Seen))
* 1847 FETCH (UID 1850 FLAGS (\Answered \Seen))
* 1848 FETCH (UID 1851 FLAGS (\Seen))
* 1849 FETCH (UID 1852 FLAGS (\Seen))
* 1850 FETCH (UID 1853 FLAGS (\Seen))
* 1851 FETCH (UID 1854 FLAGS (\Seen))
* 1852 FETCH (UID 1855 FLAGS (\Answered \Seen))
* 1853 FETCH (UID 1856 FLAGS (\Answered \Seen))
* 1854 FETCH (UID 1857 FLAGS (\Answered \Seen))
* 1855 FETCH (UID 1858 FLAGS (\Answered \Seen))
* 1856 FETCH (UID 1859 FLAGS (\Seen))
* 1857 FETCH (UID 1860 FLAGS (\Seen))
* 1858 FETCH (UID 1861 FLAGS (\Seen))
* 1859 FETCH (UID 1862 FLAGS (\Seen))
* 1860 FETCH (UID 1863 FLAGS (\Seen))
* 1861 FETCH (UID 1864 FLAGS (\Seen))
* 1862 FETCH (UID 1865 FLAGS (\Seen))
* 1863 FETCH (UID 1866 FLAGS (\Seen))
* 1864 FETCH (UID 1867 FLAGS (\Answered \Flagged \Seen))
* 1865 FETCH (UID 1868 FLAGS (\Seen))
* 1866 FETCH (UID 1869 FLAGS (\Seen))
* 1867 FETCH (UID 1870 FLAGS (\Flagged \Seen))
* 1868 FETCH (UID 1871 FLAGS (\Flagged \Seen))
* 1869 FETCH (UID 1872 FLAGS (\Seen))
* 1870 FETCH (UID 1873 FLAGS (\Seen))
* 1871 FETCH (UID 1874 FLAGS (\Seen))
* 1872 FETCH (UID 1875 FLAGS (\Seen))
* 1873 FETCH (UID 1876 FLAGS (\Seen))
* 1874 FETCH (UID 1877 FLAGS (\Seen))
* 1875 FETCH (UID 1878 FLAGS (\Seen))
* 1876 FETCH (UID 1879 FLAGS (\Seen))
* 1877 FETCH (UID 1880 FLAGS (\Seen))
* 1878 FETCH (UID 1881 FLAGS (\Answered \Seen))
* 1879 FETCH (UID 1882 FLAGS (\Seen))
1441 OK Fetch completed.
* OK [CLOSED] Previous mailbox closed.
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 38 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1279388661] UIDs valid
* OK [UIDNEXT 48] Predicted next UID
* OK [HIGHESTMODSEQ 1] Highest
1442 OK [READ-ONLY] Select completed.
* 1 FETCH (UID 1 FLAGS (\Seen))
* 2 FETCH (UID 2 FLAGS (\Seen))
* 3 FETCH (UID 3 FLAGS (\Seen))
* 4 FETCH (UID 4 FLAGS (\Seen))
* 5 FETCH (UID 5 FLAGS (\Seen))
* 6 FETCH (UID 6 FLAGS (\Seen))
* 7 FETCH (UID 7 FLAGS (\Seen))
* 8 FETCH (UID 8 FLAGS (\Seen))
* 9 FETCH (UID 9 FLAGS (\Seen))
* 10 FETCH (UID 10 FLAGS (\Seen))
* 11 FETCH (UID 11 FLAGS (\Seen))
* 12 FETCH (UID 12 FLAGS (\Seen))
* 13 FETCH (UID 13 FLAGS (\Seen))
* 14 FETCH (UID 14 FLAGS (\Seen))
* 15 FETCH (UID 15 FLAGS (\Seen))
* 16 FETCH (UID 16 FLAGS (\Seen))
* 17 FETCH (UID 17 FLAGS (\Seen))
* 18 FETCH (UID 18 FLAGS (\Seen))
* 19 FETCH (UID 19 FLAGS (\Seen))
* 20 FETCH (UID 20 FLAGS (\Seen))
* 21 FETCH (UID 21 FLAGS (\Seen))
* 22 FETCH (UID 22 FLAGS (\Seen))
* 23 FETCH (UID 23 FLAGS (\Seen))
* 24 FETCH (UID 24 FLAGS (\Seen))
* 25 FETCH (UID 25 FLAGS (\Flagged \Seen))
* 26 FETCH (UID 26 FLAGS (\Seen))
* 27 FETCH (UID 27 FLAGS (\Seen))
* 28 FETCH (UID 28 FLAGS (\Answered \Seen))
* 29 FETCH (UID 29 FLAGS (\Seen))
* 30 FETCH (UID 30 FLAGS (\Flagged \Seen))
* 31 FETCH (UID 31 FLAGS (\Flagged \Seen))
* 32 FETCH (UID 32 FLAGS (\Seen))
* 33 FETCH (UID 39 FLAGS (\Seen))
* 34 FETCH (UID 40 FLAGS (\Seen))
* 35 FETCH (UID 42 FLAGS (\Seen))
* 36 FETCH (UID 43 FLAGS (\Seen))
* 37 FETCH (UID 44 FLAGS (\Seen))
* 38 FETCH (UID 45 FLAGS (\Seen))
1443 OK Fetch completed.
* OK [CLOSED] Previous mailbox closed.
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 57 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1279379802] UIDs valid
* OK [UIDNEXT 58] Predicted next UID
* OK [HIGHESTMODSEQ 1] Highest
1444 OK [READ-ONLY] Select completed.
* 1 FETCH (UID 1 FLAGS (\Seen))
* 2 FETCH (UID 2 FLAGS (\Seen))
* 3 FETCH (UID 3 FLAGS (\Seen))
* 4 FETCH (UID 4 FLAGS (\Seen))
* 5 FETCH (UID 5 FLAGS (\Seen))
* 6 FETCH (UID 6 FLAGS (\Seen))
* 7 FETCH (UID 7 FLAGS (\Seen))
* 8 FETCH (UID 8 FLAGS (\Seen))
* 9 FETCH (UID 9 FLAGS (\Seen))
* 10 FETCH (UID 10 FLAGS (\Seen))
* 11 FETCH (UID 11 FLAGS (\Seen))
* 12 FETCH (UID 12 FLAGS (\Seen))
* 13 FETCH (UID 13 FLAGS (\Seen))
* 14 FETCH (UID 14 FLAGS (\Seen))
* 15 FETCH (UID 15 FLAGS (\Seen))
* 16 FETCH (UID 16 FLAGS (\Seen))
* 17 FETCH (UID 17 FLAGS (\Seen))
* 18 FETCH (UID 18 FLAGS (\Seen))
* 19 FETCH (UID 19 FLAGS (\Seen))
* 20 FETCH (UID 20 FLAGS (\Seen))
* 21 FETCH (UID 21 FLAGS (\Seen))
* 22 FETCH (UID 22 FLAGS (\Seen))
* 23 FETCH (UID 23 FLAGS (\Seen))
* 24 FETCH (UID 24 FLAGS (\Seen))
* 25 FETCH (UID 25 FLAGS (\Seen))
* 26 FETCH (UID 26 FLAGS (\Seen))
* 27 FETCH (UID 27 FLAGS (\Seen))
* 28 FETCH (UID 28 FLAGS (\Seen))
* 29 FETCH (UID 29 FLAGS (\Seen))
* 30 FETCH (UID 30 FLAGS (\Seen))
* 31 FETCH (UID 31 FLAGS (\Seen))
* 32 FETCH (UID 32 FLAGS (\Seen))
* 33 FETCH (UID 33 FLAGS (\Seen))
* 34 FETCH (UID 34 FLAGS (\Seen))
* 35 FETCH (UID 35 FLAGS (\Seen))
* 36 FETCH (UID 36 FLAGS (\Seen))
* 37 FETCH (UID 37 FLAGS (\Seen))
* 38 FETCH (UID 38 FLAGS (\Seen))
* 39 FETCH (UID 39 FLAGS (\Seen))
* 40 FETCH (UID 40 FLAGS (\Seen))
* 41 FETCH (UID 41 FLAGS (\Seen))
* 42 FETCH (UID 42 FLAGS (\Seen))
* 43 FETCH (UID 43 FLAGS (\Seen))
* 44 FETCH (UID 44 FLAGS (\Seen))
* 45 FETCH (UID 45 FLAGS (\Seen))
* 46 FETCH (UID 46 FLAGS (\Seen))
* 47 FETCH (UID 47 FLAGS (\Seen))
* 48 FETCH (UID 48 FLAGS (\Seen))
* 49 FETCH (UID 49 FLAGS (\Seen))
* 50 FETCH (UID 50 FLAGS (\Seen))
* 51 FETCH (UID 51 FLAGS (\Seen))
* 52 FETCH (UID 52 FLAGS (\Seen))
* 53 FETCH (UID 53 FLAGS (\Seen))
* 54 FETCH (UID 54 FLAGS (\Seen))
* 55 FETCH (UID 55 FLAGS (\Seen))
* 56 FETCH (UID 56 FLAGS (\Seen))
* 57 FETCH (UID 57 FLAGS (\Seen))
1445 OK Fetch completed.

Re: Releasing the new nnimap on y'all soon

[Knut Anders Hatlen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

>>> Added an entry, and killed the two attempts to connect using
>>> gnutls-cli (they hung, don't know why, as the commands seem to work
>>> from a terminal) so that it fell back to using openssl s_client, and
>>> then I got in.
>>
>> Huh.
>
> No idea what's going on here. Anyways, it works with openssl, so for now
> I'll just remove the gnutls-cli entries from tls-program.

I've found out what's going on now, and filed a bug against GnuTLS:
http://savannah.gnu.org/support/index.php?107481

-- 
Knut Anders

Re: "Format specifier doesn't match argument type" error message when exiting nnimap group

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> A new `g' cycle is starting at 08:55.  It starts with the folder
> "getmail" at 1424, _before_ the INBOX folder.

[...]

> 08:55:38 1442 EXAMINE "getmail"
> 08:55:38 1443 UID FETCH 1:* FLAGS

[...]

> * 1878 FETCH (UID 1881 FLAGS (\Answered \Seen))
> * 1879 FETCH (UID 1882 FLAGS (\Seen))
> 1441 OK Fetch completed.
> * OK [CLOSED] Previous mailbox closed.
> * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
> * OK [PERMANENTFLAGS ()] Read-only mailbox.
> * 38 EXISTS
> * 0 RECENT
> * OK [UIDVALIDITY 1279388661] UIDs valid
> * OK [UIDNEXT 48] Predicted next UID
> * OK [HIGHESTMODSEQ 1] Highest
> 1442 OK [READ-ONLY] Select completed.
> * 1 FETCH (UID 1 FLAGS (\Seen))
> * 2 FETCH (UID 2 FLAGS (\Seen))
> * 3 FETCH (UID 3 FLAGS (\Seen))

[...]

> * 34 FETCH (UID 40 FLAGS (\Seen))
> * 35 FETCH (UID 42 FLAGS (\Seen))
> * 36 FETCH (UID 43 FLAGS (\Seen))
> * 37 FETCH (UID 44 FLAGS (\Seen))
> * 38 FETCH (UID 45 FLAGS (\Seen))
> 1443 OK Fetch completed.

It all looks incredibly normal.

Hm...  UIDNEXT is 48, but it would have computed a high of 45 here,
since that's the highest-numbered article in the mailbox.  Perhaps
there's something odd when the highest-numbered messages are missing?
I'll try recreating that situation.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: "Format specifier doesn't match argument type" error message when exiting nnimap group

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Hm...  UIDNEXT is 48, but it would have computed a high of 45 here,
> since that's the highest-numbered article in the mailbox.  Perhaps
> there's something odd when the highest-numbered messages are missing?
> I'll try recreating that situation.

There was a bit of confusion between UIDNEXT and high, and I've now
fixed that, but I wasn't able to reproduce the bug, so this may be
unrelated. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Releasing the new nnimap on y'all soon

[Lars Magne Ingebrigtsen]

Knut Anders Hatlen <kahatlen@gmail.com> writes:

> I've found out what's going on now, and filed a bug against GnuTLS:
> http://savannah.gnu.org/support/index.php?107481

And they've fixed it already.  That was fast.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: "Format specifier doesn't match argument type" error message when exiting nnimap group

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> Hm...  UIDNEXT is 48, but it would have computed a high of 45 here,
>> since that's the highest-numbered article in the mailbox.  Perhaps
>> there's something odd when the highest-numbered messages are missing?
>> I'll try recreating that situation.

> There was a bit of confusion between UIDNEXT and high, and I've now
> fixed that, but I wasn't able to reproduce the bug, so this may be
> unrelated.

I'm guessing that particular .newsrc.eld has some duplicates that are
hidden in some circumstances, but not in others.

I.e. there are two of nnimap+privat:getmail and there are two of the
news.eclipse.org server (a problem I reported earlier, but can't
reproduce since news.eclipse.org is alive again).  But (I'm guessing
again) the duplicates are collapsed in the
*Group* and server buffer.

However... diving into newsrc.eld and fixing it, is not something I'll
do with a light heart.

Once gnus-sync.el works the way I hope it will work, I'll scrap that
.newsrc.eld and create a new one, and recreate the groups and hopefully
restore my ticks and seen values.

Re: "Format specifier doesn't match argument type" error message when exiting nnimap group

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> I.e. there are two of nnimap+privat:getmail and there are two of the
> news.eclipse.org server (a problem I reported earlier, but can't
> reproduce since news.eclipse.org is alive again).  But (I'm guessing
> again) the duplicates are collapsed in the
> *Group* and server buffer.

Oh.  Yes, duplicate groups will result in all kinds of oddities.  Didn't
I write something to remove duplicate groups?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: "Format specifier doesn't match argument type" error message when exiting nnimap group

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Oh.  Yes, duplicate groups will result in all kinds of oddities.  Didn't
> I write something to remove duplicate groups?

After this morning's "git pull", the "ghost" article in
nnimap+privat:getmail has gone away.

So some change in the last 24h has fixed this...:-)

Re: "Format specifier doesn't match argument type" error message when exiting nnimap group

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> After this morning's "git pull", the "ghost" article in
> nnimap+privat:getmail has gone away.
>
> So some change in the last 24h has fixed this...:-)

Yay.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen