gnus uses a cache?

gnus uses a cache?

[Sharon Kimble]

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

I've come to the conclusion that there is some kind of caching going on
with gnus, and that if I close my gnus down when I hit some problems,
and then not open or use it in any form for over 5 hours, the cache
forgets and the problem is solved! The figure of 5 hours is purely
arbitrary, just plucked out of thin air!

Am I right?

Sharon.
-- 
A taste of linux = http://www.sharons.org.uk
my git repo = https://bitbucket.org/boudiccas/dots
TGmeds = http://www.tgmeds.org.uk
Debian testing, fluxbox 1.3.5, emacs 24.3.93.1

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: gnus uses a cache?

[Adam Sjøgren]

Sharon Kimble <boudiccas@skimble.plus.com> writes:

> Am I right?

It sounds more like you've joined a cargo cult.


  Best regards,

    Adam

-- 
 "The forensic marvel has reduced my logic to shambles."       Adam Sjøgren
                                                         asjo@koldfront.dk

Re: gnus uses a cache?

[James Cloos]

>>>>> "SK" == Sharon Kimble <boudiccas@skimble.plus.com> writes:

SK> I've come to the conclusion that there is some kind of caching going
SK> on with gnus,

There is some caching of articles w/in a given session, but nothing I'm
aware of which would survive a restart.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: gnus uses a cache? And how it affects mairix searches...

[Dan Christensen]

[Sorry to hijack the thread.  Subject adjusted.]

James Cloos <cloos@jhcloos.com> 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

Re: gnus uses a cache? And how it affects mairix searches...

[Dan Christensen]

Dan Christensen <jdc@uwo.ca> writes:

> [Sorry to hijack the thread.  Subject adjusted.]
>
> James Cloos <cloos@jhcloos.com> 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?

Dan

Re: gnus uses a cache? And how it affects mairix searches...

[Eric Abrahamsen]

Dan Christensen <jdc@uwo.ca> writes:

> Dan Christensen <jdc@uwo.ca> writes:
>
>> [Sorry to hijack the thread.  Subject adjusted.]
>>
>> James Cloos <cloos@jhcloos.com> 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...

Re: gnus uses a cache? And how it affects mairix searches...

[Eric Abrahamsen]

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

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Dan Christensen <jdc@uwo.ca> writes:
>
>> Dan Christensen <jdc@uwo.ca> writes:
>>
>>> [Sorry to hijack the thread.  Subject adjusted.]
>>>
>>> James Cloos <cloos@jhcloos.com> 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.


[-- Attachment #2: nnir.png --]
[-- Type: image/png, Size: 80333 bytes --]

Re: gnus uses a cache? And how it affects mairix searches...

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Dan Christensen <jdc@uwo.ca> writes:
>>
>>> Dan Christensen <jdc@uwo.ca> writes:
>>>
>>>> [Sorry to hijack the thread.  Subject adjusted.]
>>>>
>>>> James Cloos <cloos@jhcloos.com> 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.

And yes, that worked. My guess is that gnus should just not enter
articles into the backlog if they came from a search-composed group.

Ie, the check at the very top of `gnus-backlog-enter-article' needs to
be expanded. I thought that gnus-ephemeral-group-p might be the right
check, but that doesn't flag nnir/nnmairix groups. I need to run out,
but will look at this more later -- or if anyone knows a nice clean
filter, rather than checking against a bunch of regexps?

Eric

Re: gnus uses a cache? And how it affects mairix searches...

[Alan Schmitt]

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

On 2014-10-22 16:30, Eric Abrahamsen <eric@ericabrahamsen.net> writes:

>>> 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.
>
> And yes, that worked. My guess is that gnus should just not enter
> articles into the backlog if they came from a search-composed group.

Thank you for that suggestion. This bug has been bugging me for a while
(when I jump to a message from a notmuch search), and I had no idea how
to address it.

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 494 bytes --]

Re: gnus uses a cache? And how it affects mairix searches...

[Eric Abrahamsen]

Dan Christensen <jdc@uwo.ca> writes:

> Dan Christensen <jdc@uwo.ca> writes:
>
>> [Sorry to hijack the thread.  Subject adjusted.]
>>
>> James Cloos <cloos@jhcloos.com> 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?
>
> Dan

Can you or someone else using nnmairix tell me if calling
(gnus-virtual-group-p "nnmairix:your group name") returns t? It's true
for nnvirtual and nnir groups, so that function might make a good guard
inside `gnus-backlog-enter-article'.

Eric

Re: gnus uses a cache? And how it affects mairix searches...

[Dan Christensen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Dan Christensen <jdc@uwo.ca> writes:
>
>> 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?
>>
>> Dan
>
> Can you or someone else using nnmairix tell me if calling
> (gnus-virtual-group-p "nnmairix:your group name") returns t? It's true
> for nnvirtual and nnir groups, so that function might make a good guard
> inside `gnus-backlog-enter-article'.
>
> Eric

Unfortunately, that doesn't work:

(gnus-virtual-group-p "nnmairix+mairixserver:nnmairixsearch")
nil

So maybe a combination of checks is needed.  Or just check if the
backend is in a banned list which includes nnmairix, nnir, etc.
This is what the registry does in gnus.el:

;; The Gnus registry's ignored groups
(gnus-define-group-parameter
 registry-ignore
 :type list
 :function-document
 "Whether this group should be ignored by the registry."
 :variable gnus-registry-ignored-groups
 :variable-default (mapcar
                    (lambda (g) (list g t))
                    '("delayed$" "drafts$" "queue$" "INBOX$"
                      "^nnmairix:" "^nnir:" "archive"))
...

Or maybe gnus-virtual-group-p should be changed to declare that nnmairix
groups are virtual?  This could be accomplished by changing
gnus-valid-select-methods.  In gnus.el, it doesn't list nnmairix at all,
but somehow when using nnmairix, an entry for nnmairix gets added to
this list, without the virtual keyword (see below).

I don't know enough about the internals to know the best way to
proceed.

Dan


gnus-valid-select-methods is a variable defined in `gnus.el'.

Value: (("nntp" post address prompt-address physical-address cloud)
 ("nnspool" post address)
 ("nnvirtual" post-mail virtual prompt-address)
 ("nnmbox" mail respool address)
 ("nnml" post-mail respool address)
 ("nnmh" mail respool address)
 ("nndir" post-mail prompt-address physical-address)
 ("nneething" none address prompt-address physical-address)
 ("nndoc" none address prompt-address)
 ("nnbabyl" mail address respool)
 ("nndraft" post-mail)
 ("nnfolder" mail respool address)
 ("nngateway" post-mail address prompt-address physical-address)
 ("nnweb" none)
 ("nnrss" none global)
 ("nnagent" post-mail)
 ("nnimap" post-mail address prompt-address physical-address respool server-marks cloud)
 ("nnmaildir" mail respool address server-marks)
 ("nnnil" none)
 ("nnmairix" mail address)
 ("nnir" mail virtual))

Re: gnus uses a cache? And how it affects mairix searches...

[Andreas Schwab]

Dan Christensen <jdc@uwo.ca> writes:

> In gnus.el, it doesn't list nnmairix at all, but somehow when using
> nnmairix, an entry for nnmairix gets added to this list, without the
> virtual keyword (see below).

diff --git a/lisp/nnmairix.el b/lisp/nnmairix.el
index 0cef699..b2f74e3 100644
--- a/lisp/nnmairix.el
+++ b/lisp/nnmairix.el
@@ -417,7 +417,7 @@ Other back ends might or might not work.")
 
 (nnoo-define-basics nnmairix)
 
-(gnus-declare-backend "nnmairix" 'mail 'address)
+(gnus-declare-backend "nnmairix" 'mail 'address 'virtual)
 
 (deffoo nnmairix-open-server (server &optional definitions)
   ;; just set server variables

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gnus uses a cache? And how it affects mairix searches...

[Eric Abrahamsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Dan Christensen <jdc@uwo.ca> writes:
>
>> In gnus.el, it doesn't list nnmairix at all, but somehow when using
>> nnmairix, an entry for nnmairix gets added to this list, without the
>> virtual keyword (see below).
>
> diff --git a/lisp/nnmairix.el b/lisp/nnmairix.el
> index 0cef699..b2f74e3 100644
> --- a/lisp/nnmairix.el
> +++ b/lisp/nnmairix.el
> @@ -417,7 +417,7 @@ Other back ends might or might not work.")
>  
>  (nnoo-define-basics nnmairix)
>  
> -(gnus-declare-backend "nnmairix" 'mail 'address)
> +(gnus-declare-backend "nnmairix" 'mail 'address 'virtual)
>  
>  (deffoo nnmairix-open-server (server &optional definitions)
>    ;; just set server variables
>
> Andreas.

After look at this for a while, I do think this is the right solution --
what do you all think? Can someone apply this change?

Re: gnus uses a cache? And how it affects mairix searches...

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> Dan Christensen <jdc@uwo.ca> writes:
>>
>>> In gnus.el, it doesn't list nnmairix at all, but somehow when using
>>> nnmairix, an entry for nnmairix gets added to this list, without the
>>> virtual keyword (see below).
>>
>> diff --git a/lisp/nnmairix.el b/lisp/nnmairix.el
>> index 0cef699..b2f74e3 100644
>> --- a/lisp/nnmairix.el
>> +++ b/lisp/nnmairix.el
>> @@ -417,7 +417,7 @@ Other back ends might or might not work.")
>>  
>>  (nnoo-define-basics nnmairix)
>>  
>> -(gnus-declare-backend "nnmairix" 'mail 'address)
>> +(gnus-declare-backend "nnmairix" 'mail 'address 'virtual)
>>  
>>  (deffoo nnmairix-open-server (server &optional definitions)
>>    ;; just set server variables
>>
>> Andreas.
>
> After look at this for a while, I do think this is the right solution --
> what do you all think? Can someone apply this change?

Oh never mind, I guess I didn't look long enough. For any backend
declared as virtual, `gnus-cache-possibly-enter-article' will use
`nnvirtual-find-group-art' to get the real group name.

That means that if a backend is declared 'virtual but isn't actually
nnvirtual, the caching mechanism will use the wrong lookup function.

nnir should use `nnir-article-group'

nnmairix could probably do it with a little massaging of
`nnmairix-determine-original-group-from-path'.

What we'd really want is a properly-abstracted nnoo function that
virtual backends would use to locate the real article.

In the meantime, it would probably be enough to make
`gnus-uncacheable-groups' match nnmairix and nnir groups.

Eric

Re: gnus uses a cache? And how it affects mairix searches...

[Dan Christensen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Andreas Schwab <schwab@linux-m68k.org> writes:
>>
>>> Dan Christensen <jdc@uwo.ca> writes:
>>>
>>>> In gnus.el, it doesn't list nnmairix at all, but somehow when using
>>>> nnmairix, an entry for nnmairix gets added to this list, without the
>>>> virtual keyword (see below).
>>>
>>> diff --git a/lisp/nnmairix.el b/lisp/nnmairix.el
>>> index 0cef699..b2f74e3 100644
>>> --- a/lisp/nnmairix.el
>>> +++ b/lisp/nnmairix.el
>>> @@ -417,7 +417,7 @@ Other back ends might or might not work.")
>>>  
>>>  (nnoo-define-basics nnmairix)
>>>  
>>> -(gnus-declare-backend "nnmairix" 'mail 'address)
>>> +(gnus-declare-backend "nnmairix" 'mail 'address 'virtual)
>>>  
>>>  (deffoo nnmairix-open-server (server &optional definitions)
>>>    ;; just set server variables
>>>
>>> Andreas.
>>
>> After look at this for a while, I do think this is the right solution --
>> what do you all think? Can someone apply this change?
>
> Oh never mind, I guess I didn't look long enough. For any backend
> declared as virtual, `gnus-cache-possibly-enter-article' will use
> `nnvirtual-find-group-art' to get the real group name.
>
> That means that if a backend is declared 'virtual but isn't actually
> nnvirtual, the caching mechanism will use the wrong lookup function.

I don't follow you.  Isn't the relevant function gnus-backlog-enter-article,
which skips the backlog for groups that are declared virtual?

I haven't actually tested the patch and instead simply disabled the
backlog entirely, but I suspect the patch will work.

Dan

Re: gnus uses a cache? And how it affects mairix searches...

[Eric Abrahamsen]

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

Dan Christensen <jdc@uwo.ca> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>> Andreas Schwab <schwab@linux-m68k.org> writes:
>>>
>>>> Dan Christensen <jdc@uwo.ca> writes:
>>>>
>>>>> In gnus.el, it doesn't list nnmairix at all, but somehow when using
>>>>> nnmairix, an entry for nnmairix gets added to this list, without the
>>>>> virtual keyword (see below).
>>>>
>>>> diff --git a/lisp/nnmairix.el b/lisp/nnmairix.el
>>>> index 0cef699..b2f74e3 100644
>>>> --- a/lisp/nnmairix.el
>>>> +++ b/lisp/nnmairix.el
>>>> @@ -417,7 +417,7 @@ Other back ends might or might not work.")
>>>>  
>>>>  (nnoo-define-basics nnmairix)
>>>>  
>>>> -(gnus-declare-backend "nnmairix" 'mail 'address)
>>>> +(gnus-declare-backend "nnmairix" 'mail 'address 'virtual)
>>>>  
>>>>  (deffoo nnmairix-open-server (server &optional definitions)
>>>>    ;; just set server variables
>>>>
>>>> Andreas.
>>>
>>> After look at this for a while, I do think this is the right solution --
>>> what do you all think? Can someone apply this change?
>>
>> Oh never mind, I guess I didn't look long enough. For any backend
>> declared as virtual, `gnus-cache-possibly-enter-article' will use
>> `nnvirtual-find-group-art' to get the real group name.
>>
>> That means that if a backend is declared 'virtual but isn't actually
>> nnvirtual, the caching mechanism will use the wrong lookup function.
>
> I don't follow you.  Isn't the relevant function gnus-backlog-enter-article,
> which skips the backlog for groups that are declared virtual?
>
> I haven't actually tested the patch and instead simply disabled the
> backlog entirely, but I suspect the patch will work.

Ha, yes! Between then and now I somehow started looking at the wrong
mechanism altogether. Sorry about that.

I've attached patches for both the backlog edit and the nnmairix edit.

Eric



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Mark-nnmairix-as-a-virtual-backend.patch --]
[-- Type: text/x-diff, Size: 796 bytes --]

From 0f70f9fedda2de3a424384272c2e1adfdad9fdd7 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen <eric@ericabrahamsen.net>
Date: Thu, 13 Nov 2014 08:15:35 +0800
Subject: [PATCH 1/2] Mark nnmairix as a virtual backend

* lisp/nnmairix.el: Add 'virtual to call to `gnus-declare-backend'
---
 lisp/nnmairix.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/nnmairix.el b/lisp/nnmairix.el
index 0cef699..b2f74e3 100644
--- a/lisp/nnmairix.el
+++ b/lisp/nnmairix.el
@@ -417,7 +417,7 @@ Other back ends might or might not work.")
 
 (nnoo-define-basics nnmairix)
 
-(gnus-declare-backend "nnmairix" 'mail 'address)
+(gnus-declare-backend "nnmairix" 'mail 'address 'virtual)
 
 (deffoo nnmairix-open-server (server &optional definitions)
   ;; just set server variables
-- 
2.1.3


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Disable-backlog-altogethe-for-virtual-groups.patch --]
[-- Type: text/x-diff, Size: 884 bytes --]

From f297d0bdc31e69661ad3e09279e16fd6605da621 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen <eric@ericabrahamsen.net>
Date: Thu, 13 Nov 2014 08:16:13 +0800
Subject: [PATCH 2/2] Disable backlog altogethe for virtual groups

* lisp/gnus-bcklg.el (gnus-backlog-enter-article): No articles from
  virtual groups should be added to the backlog.
---
 lisp/gnus-bcklg.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/gnus-bcklg.el b/lisp/gnus-bcklg.el
index db80800..eb3c9f0 100644
--- a/lisp/gnus-bcklg.el
+++ b/lisp/gnus-bcklg.el
@@ -61,7 +61,7 @@
 
 (defun gnus-backlog-enter-article (group number buffer)
   (when (and (numberp number)
-	     (not (string-match "^nnvirtual" group)))
+	     (not (gnus-virtual-group-p group)))
     (gnus-backlog-setup)
     (let ((ident (intern (concat group ":" (int-to-string number))
 			 gnus-backlog-hashtb))
-- 
2.1.3

Re: gnus uses a cache? And how it affects mairix searches...

[Dan Christensen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I've attached patches for both the backlog edit and the nnmairix edit.

...

>  (defun gnus-backlog-enter-article (group number buffer)
>    (when (and (numberp number)
> -	     (not (string-match "^nnvirtual" group)))
> +	     (not (gnus-virtual-group-p group)))

I guess gnus-backlog-request-article should have a similar change made?

Dan

Re: gnus uses a cache? And how it affects mairix searches...

[Eric Abrahamsen]

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

Dan Christensen <jdc@uwo.ca> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I've attached patches for both the backlog edit and the nnmairix edit.
>
> ...
>
>>  (defun gnus-backlog-enter-article (group number buffer)
>>    (when (and (numberp number)
>> -	     (not (string-match "^nnvirtual" group)))
>> +	     (not (gnus-virtual-group-p group)))
>
> I guess gnus-backlog-request-article should have a similar change made?
>
> Dan

Good point! New patches...


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Mark-nnmairix-as-a-virtual-backend.patch --]
[-- Type: text/x-diff, Size: 796 bytes --]

From 4444ddab84c4bde3ad6db3ae03a937816e3a0523 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen <eric@ericabrahamsen.net>
Date: Thu, 13 Nov 2014 08:15:35 +0800
Subject: [PATCH 1/2] Mark nnmairix as a virtual backend

* lisp/nnmairix.el: Add 'virtual to call to `gnus-declare-backend'
---
 lisp/nnmairix.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/nnmairix.el b/lisp/nnmairix.el
index 0cef699..b2f74e3 100644
--- a/lisp/nnmairix.el
+++ b/lisp/nnmairix.el
@@ -417,7 +417,7 @@ Other back ends might or might not work.")
 
 (nnoo-define-basics nnmairix)
 
-(gnus-declare-backend "nnmairix" 'mail 'address)
+(gnus-declare-backend "nnmairix" 'mail 'address 'virtual)
 
 (deffoo nnmairix-open-server (server &optional definitions)
   ;; just set server variables
-- 
2.1.3


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Disable-backlog-altogether-for-virtual-groups.patch --]
[-- Type: text/x-diff, Size: 1254 bytes --]

From 199e227482b78171d88820fb22008cadd01641ac Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen <eric@ericabrahamsen.net>
Date: Sun, 16 Nov 2014 11:28:35 +0800
Subject: [PATCH 2/2] Disable backlog altogether for virtual groups

* lisp/gnus-bcklg.el (gnus-backlog-enter-article
  gnus-backlog-request-article): No articles from virtual groups
  should be added to the backlog.
---
 lisp/gnus-bcklg.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/gnus-bcklg.el b/lisp/gnus-bcklg.el
index db80800..f3b9a66 100644
--- a/lisp/gnus-bcklg.el
+++ b/lisp/gnus-bcklg.el
@@ -61,7 +61,7 @@
 
 (defun gnus-backlog-enter-article (group number buffer)
   (when (and (numberp number)
-	     (not (string-match "^nnvirtual" group)))
+	     (not (gnus-virtual-group-p group)))
     (gnus-backlog-setup)
     (let ((ident (intern (concat group ":" (int-to-string number))
 			 gnus-backlog-hashtb))
@@ -126,7 +126,7 @@
 
 (defun gnus-backlog-request-article (group number &optional buffer)
   (when (and (numberp number)
-	     (not (string-match "^nnvirtual" group)))
+	     (not (gnus-virtual-group-p group)))
     (gnus-backlog-setup)
     (let ((ident (intern (concat group ":" (int-to-string number))
 			 gnus-backlog-hashtb))
-- 
2.1.3

Re: gnus uses a cache? And how it affects mairix searches...

[Lars Ingebrigtsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Good point! New patches...

Thanks; applied.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: gnus uses a cache?

[Ted Zlatanov]

On Sat, 06 Sep 2014 23:36:24 +0100 Sharon Kimble <boudiccas@skimble.plus.com> wrote: 

SK> I've come to the conclusion that there is some kind of caching going on
SK> with gnus, and that if I close my gnus down when I hit some problems,
SK> and then not open or use it in any form for over 5 hours, the cache
SK> forgets and the problem is solved! The figure of 5 hours is purely
SK> arbitrary, just plucked out of thin air!

Why don't you describe the problems and how to replicate them?  Often
that triggers an "aha" moment.

Ted