From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.user/17818 Path: news.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.gnus.user Subject: Re: Finding message by ID fails when message not visible Date: Thu, 17 Dec 2015 10:08:31 +0800 Message-ID: <877fkdvnc0.fsf@ericabrahamsen.net> References: <87wpsfb5jh.fsf@ericabrahamsen.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1450318144 24593 80.91.229.3 (17 Dec 2015 02:09:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 17 Dec 2015 02:09:04 +0000 (UTC) To: info-gnus-english@gnu.org Original-X-From: info-gnus-english-bounces+gegu-info-gnus-english=m.gmane.org@gnu.org Thu Dec 17 03:08:50 2015 Return-path: Envelope-to: gegu-info-gnus-english@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a9Nzt-0000pN-Pv for gegu-info-gnus-english@m.gmane.org; Thu, 17 Dec 2015 03:08:50 +0100 Original-Received: from localhost ([::1]:50398 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9Nzt-0003Nv-0V for gegu-info-gnus-english@m.gmane.org; Wed, 16 Dec 2015 21:08:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50963) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9Nzq-0003Nc-3O for info-gnus-english@gnu.org; Wed, 16 Dec 2015 21:08:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9Nzl-0002T6-W5 for info-gnus-english@gnu.org; Wed, 16 Dec 2015 21:08:46 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:46057) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9Nzl-0002Sw-Ly for info-gnus-english@gnu.org; Wed, 16 Dec 2015 21:08:41 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1a9Nzj-0000UR-Gh for info-gnus-english@gnu.org; Thu, 17 Dec 2015 03:08:39 +0100 Original-Received: from 49.65.153.225 ([49.65.153.225]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Dec 2015 03:08:39 +0100 Original-Received: from eric by 49.65.153.225 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 17 Dec 2015 03:08:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 112 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 49.65.153.225 User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1.50 (gnu/linux) Cancel-Lock: sha1:REOhYKLMifnmEXfeqgIvlrbs1ic= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: info-gnus-english@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Announcements and discussions for GNUS, the GNU Emacs Usenet newsreader \(in English\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: info-gnus-english-bounces+gegu-info-gnus-english=m.gmane.org@gnu.org Original-Sender: info-gnus-english-bounces+gegu-info-gnus-english=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.gnus.user:17818 Archived-At: Kai von Fintel writes: > Kai von Fintel writes: > >> Eric Abrahamsen writes: >> >>> Kai von Fintel writes: >>> >>>> I'm puzzled by the following behavior: if I search in an nnimap group >>>> for a message with a particular message-ID, the search fails unless the >>>> message is visible. If for example, only new messages are shown, the >>>> search for an old message with a particular ID fails but the same >>>> message is found when "/o" has made the old messages appear. >>>> >>>> This is relevant because I use links to gnus messages from org-mode and >>>> more often than not the link fails: I get taken to the nnimap group that >>>> contains the message, but I get the error "No such article (may have >>>> expired or been canceled)", even though the message is in fact in the >>>> group. >>>> >>>> I suppose org-gnus.el might have to be amended to work around this, but >>>> first I'd like to understand whether this is expected behavior in gnus. >>>> >>>> Can anybody enlighten me or help me trouble-shoot this? >>> >>> No, it's not expected, and I haven't seen it before -- sorry for the >>> unhelpful reply! I just tried it (dovecot imap server), and it worked >>> both with and without angle brackets on the ID (sometimes brackets can >>> be an issue). >>> >>> To be sure everyone's on the same page, how exactly are you searching? >>> If you're in the *Group* buffer and you hit "G G" on the group, and >>> paste in the message ID, is the message found? If you're already in the >>> *Summary* buffer, there isn't really any way to "search" as such, >>> there's only "limiting" what messages are shown by some criteria -- in >>> those cases it's true you won't be able to get to unseen messages. >>> >>> But that should never affect following links from org mode... >>> >>> Eric >> >> Thanks for the reply, Eric. More details then. >> >> 1. GG in the group buffer works (after a brief delay, displaying >> "Opening server FastmailLocal" and then "Searching >> nnimap+FastmailLocal:Archive...done"). >> >> 2. M-^ ("Fetch article with id ...) in the summary buffer (a) works when >> the message is visible, (b) fails when the message isn't visible (with >> "No such article (may have expired or been canceled)"). >> >> 3. When I follow the org link, say >> "gnus:nnimap+FastmailLocal:Archive#56614DE9.5030300@upf.edu", I do get >> taken to the right nnimap group in gnus but the article is not displayed >> (again, with "No such article (may have expired or been canceled)"). >> >> One funny thing is that when the "search" fails (in both cases 2b and >> 3), the article summary actually is visible (see screenshot: >> https://www.dropbox.com/s/b1b9mxi7bl0a51j/missing-article.jpg?dl=0) >> >> If 1 and 2 are as expected, then I guess the issue is with org-gnus and >> how it interacts with my IMAP set-up (offlineimap + dovecot + nnimap)? >> >> -- Kai. > > Some more follow-up. I tried to understand the code in org-gnus.el and > org-sum.el. It appears that the functions "org-gnus-open" and > "org-gnus-follow-link" call the function "gnus-summary-goto-article" > from gnus-sum.el. The latter is called with the optional arguments "nil" > and "t". The last one is supposed to force that all articles are loaded, > but that doesn't seem to happen. > > When I call (gnus-summary-goto-article "56614DE9.5030300@upf.edu" nil t) > in the summary buffer of the relevant group, it finds the message when > it is listed and doesn't find it if the buffer has only the first 200 > articles (loading all articles with "/o" then makes the function > succeed). > > I added (gnus-large-newsgroup nil) to the group parameters, which then > loads all articles when entering the group, and > (gnus-summary-goto-article "56614DE9.5030300@upf.edu" nil t) then > succeeds in the summary buffer. > > However, the gnus link still doesn't work from outside gnus. It's as if > the FORCE optional argument that is given to "gnus-summary-goto-article" > has no effect. I've got the same setup as you (Gnus and local dovecot), but perhaps the versions are different? Can you tell us your versions for Gnus and Org? When I step through `gnus-summary-goto-article', searching for a message ID that is *not* currently display, the "force" argument never even comes into play. I end up in this branch: (if (and (stringp article) (string-match "@\\|%40" article)) (gnus-summary-refer-article article) So then on to `gnus-summary-refer-article' (no force argument used), and in that function I end up in the "t" branch of the "cond" later on, and eventually into "(gnus-summary-insert-subject message-id)". Then that leads to "(gnus-read-header id)", and all is well. I know this is tedious, but would you mind stepping through with edebug and seeing where things fall apart? My off-the-cuff guess is that you're using an older version of Gnus where the nnimap backend isn't quite all put together... If you aren't comfortable with edebug let me know and I can provide exact instructions. It's a very useful thing to know! Eric