Eric Abrahamsen writes: > Dan Christensen writes: > >> Dan Christensen writes: >> >>> [Sorry to hijack the thread. Subject adjusted.] >>> >>> James Cloos writes: >>> >>>> There is some caching of articles w/in a given session, but nothing I'm >>>> aware of which would survive a restart. >>> >>> Since upgrading Ubuntu and Gnus, I've noticed that the results of >>> nnmairix searches infiltrate subsequent search results. More precisely, >>> the second time I do a search, the summary buffer looks correct, but for >>> some of the articles, when I select them the *Article* buffer shows the >>> articles from the previous search. The third search may show article >>> buffers from the first or second search (or both). >>> >>> My search results are stored in a local imap folder (dovecot), and I >>> have verified that on disk the correct articles are stored. I have also >>> verified that if I connect to dovecot via telnet, it displays the >>> correct article bodies. I am not using the agent (as far as I know). >>> >>> I have also tried various nnmairix keystrokes to redo searches, etc, >>> and none of them helped. >>> >>> Any idea why this is happening? nnmairix used to work beautifully for >>> me. >>> >>> Dan >> >> I finally figured this out. Setting gnus-keep-backlog to nil solved >> the problem. It turns out that by default, gnus caches the most recent >> 20 articles you have viewed, rather than contacting the server again. >> This is true even if you exit and reenter a summary buffer. >> >> Maybe nnmairix should remove articles from this cache when it creates >> a search folder? Or bind this variable to nil in nnmairix groups? > > Hmm, I may have seen this in nnir groups, as well. At least, I've (only > once or twice) had a similar situation: selecting articles in an nnir > search summary buffer, and seeing article bodies from the last search. I > can only assume it's the same problem... Just had it again! See attachment -- the article body shown when selecting one summary line actually belongs to a different summary line. This time it seems fairly reproducible (and is messing with Gnorb-related stuff) so I'll see if I figure it out, starting with setting gnus-keep-backlog to 0.