[Orgmode] Re: Behavior of Gnus when called from an hyperlink

[Tassilo Horn]

Sébastien Vauban <address@hidden>
writes:

Hi Sébastien,

> The function `nnimap-request-article-part' gets called several times.
>
> --8<---------------cut here---------------start------------->8---
> (defun nnimap-request-article-part (article part prop &optional
>                                           group server to-buffer detail)
>   (when (nnimap-possibly-change-group group server)
>     (let ((article (if (stringp article)
>                      (car-safe (imap-search
>                                 (format "HEADER Message-Id \"%s\"" article)
>                                 nnimap-server-buffer))
>                    article)))
>       (when article
>       ;; [...]
> --8<---------------cut here---------------end--------------->8---
>
> The first couple of times happen quickly, with `article' 140579, then
> 140580, then 140581.
>
> After that, (real) things happen:
>
> --8<---------------cut here---------------start------------->8---
> IMAP split moved mc:INBOX:140581 to INBOX.scorpios
> nnimap: Updating info for nnimap+mc:INBOX.mc...done
> Retrieving newsgroup: nnimap+mc:INBOX.mc...
> nnimap: Updating info for nnimap+mc:INBOX.mc...done
> Fetching headers for nnimap+mc:INBOX.mc...done
> Scoring...done
> Making sparse threads...done
> Sorting threads...done
> Generating summary...done
> No more unread articles
> --8<---------------cut here---------------end--------------->8---
>
> and I have the top buffer displaying the subject of the linked article
> I'm after. Already something...
>
> What follows is stepping another time in the function
> `nnimap-request-article-part', this time with `article'
> "<address@hidden>" (not a
> number anymore).
>
> I'm then directed in the "then" part of the "if-then-else" (testing if
> `article' is a string or not).
>
> And, then, what stops me for 5 mins is the `imap-search' call.

Hm, ok.  So it seems that fetching an article by its Message-id is the
slow part.  And of course, org-gnus *always* fetches by message-ids,
couse that's the message attribute you can rely on.  Article numbers are
not that static: for example when moving messages to another group and
back again... (Some people do that to fill gaps in the article numbers
and fix the "wrong unread count" issue.)

> I guess I will have to dive that side (not now -- going to sleep).
> Don't know if that gives hints yet, or not...

Well, now we know that there are issues when searching for a message-id.
Please go on edebugging `imap-search'. ;-)

Please check, if that function is that slow for all message-ids or if
that's only for some.  The function has a "FIXME: Should this try to use
CHARSET?  -- fx", and maybe this answer has to be answered with Yes!

And check what's in the buffer that function operates on:
`nnimap-server-buffer'.

As a side-node: Since lately, my gnus hangs when I try to post to our
university's newsserver using a TLS or SSL connection.  Without an
encrypted connection, it works again.  I don't have a clue what's going
wrong, but somehow there's a miscommunication between gnus and the
server...

Bye,
Tassilo