nnimap usage model

nnimap usage model

[David Abrahams]

Hi, 

I was convinced to try IMAP by a friend who uses Mulberry to read mail
(and wishes he could edit in gnus/Emacs!)  His usage model sounds like
it would suit my needs well; basically he keeps a local copy of all of
his messages for fast searching, and so that he can easily work
"unplugged".  I'm having a hard time replicating that, especially the
unplugged part. I do have:

(setq
      gnus-cacheable-groups "^nnimap*"
      gnus-use-cache t)

But it seems to go back to the server a lot, especially to retrieve
headers.  Also I can't look at my messages at all in "unplugged" Agent
mode.  What am I missing?

BTW, I also wonder if it's possible to get GNUs to cache its notion of
each group's headers (summary buffer) between sessions.  My other
programs (Mulberry, Outlook Express) do that and that's one among many
other factors which seems to make them feel a lot more responsive than GNUs.

Thanks in advance,
Dave

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: nnimap usage model

[Kai Großjohann]

David Abrahams <dave@boost-consulting.com> writes:

> I was convinced to try IMAP by a friend who uses Mulberry to read mail
> (and wishes he could edit in gnus/Emacs!)  His usage model sounds like
> it would suit my needs well; basically he keeps a local copy of all of
> his messages for fast searching, and so that he can easily work
> "unplugged".  I'm having a hard time replicating that, especially the
> unplugged part.

You should use the Agent, I think.  Also search for "plugged" and
"unplugged" in the Gnus info file.
-- 
A turnip curses Elvis

Re: nnimap usage model

[Niklas Morberg]

David Abrahams <dave@boost-consulting.com> writes:

> basically he keeps a local copy of all of his messages for
> fast searching, and so that he can easily work
> "unplugged".

I'm after this functionality myself and use the agent like
so:

 '(gnus-agent t)
 '(gnus-agent-consider-all-articles t)
 '(gnus-agent-expire-days 36500)
 '(gnus-agent-mark-unread-after-downloaded nil)

There are a couple of problems with this approach: e.g. I
have to run gnus-agent-regenerate a couple of times each day
since something gets out of whack, and the summary buffer
gets terribly confused at times and displays messages that
are just not there.

I haven't had the time to look more closely at when these
problems occur, so I can't be more specific. I'm a lot less
happy with gnus since I started using the agent, though :(

Niklas

Re: nnimap usage model

[Kai Großjohann]

Niklas Morberg <niklas.morberg@axis.com> writes:

> There are a couple of problems with this approach: e.g. I have to
> run gnus-agent-regenerate a couple of times each day since something
> gets out of whack, and the summary buffer gets terribly confused at
> times and displays messages that are just not there.

Amazing.  I have the occasional problem, but nothing like this.  The
author/subject data and suchlike appears to be correct.

Hm.  Do you see this in nnimap groups only, or also in nntp groups?
What's your imap server?  I'm wildly guessing it might have something
to do with uidvalidity.

-- 
A turnip curses Elvis

Re: nnimap usage model

[David Abrahams]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> David Abrahams <dave@boost-consulting.com> writes:
>
>> I was convinced to try IMAP by a friend who uses Mulberry to read mail
>> (and wishes he could edit in gnus/Emacs!)  His usage model sounds like
>> it would suit my needs well; basically he keeps a local copy of all of
>> his messages for fast searching, and so that he can easily work
>> "unplugged".  I'm having a hard time replicating that, especially the
>> unplugged part.
>
> You should use the Agent, I think.  Also search for "plugged" and
> "unplugged" in the Gnus info file.

Wow, thanks for the fast reply, but it looks like you only read half
of my message... or am I misunderstanding?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: nnimap usage model

[David Abrahams]

Niklas Morberg <niklas.morberg@axis.com> writes:

> David Abrahams <dave@boost-consulting.com> writes:
>
>> basically he keeps a local copy of all of his messages for
>> fast searching, and so that he can easily work
>> "unplugged".
>
> I'm after this functionality myself and use the agent like
> so:
>
>  '(gnus-agent t)
>  '(gnus-agent-consider-all-articles t)
>  '(gnus-agent-expire-days 36500)
>  '(gnus-agent-mark-unread-after-downloaded nil)
>
> There are a couple of problems with this approach: e.g. I
> have to run gnus-agent-regenerate a couple of times each day
> since something gets out of whack, and the summary buffer
> gets terribly confused at times and displays messages that
> are just not there.
>
> I haven't had the time to look more closely at when these
> problems occur, so I can't be more specific. I'm a lot less
> happy with gnus since I started using the agent, though :(

This is so sad :(.  It doesn't sound like your arrangement is worth
the likely frustration.

I can't imagine GNUs ever being as smooth as Mulberry is, and I can't
imagine enjoying the UI design of Mulberry the way I do GNUs.  If only
I could just use emacs as a back-end for the Mulberry core!

Ah, well, I guess I can dream...

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: nnimap usage model

[Kevin Greiner]

David Abrahams <dave@boost-consulting.com> writes:

> Niklas Morberg <niklas.morberg@axis.com> writes:
>
>> David Abrahams <dave@boost-consulting.com> writes:
>>
>>> basically he keeps a local copy of all of his messages for
>>> fast searching, and so that he can easily work
>>> "unplugged".
>>
>> I'm after this functionality myself and use the agent like
>> so:
>>
>>  '(gnus-agent t)
>>  '(gnus-agent-consider-all-articles t)
>>  '(gnus-agent-expire-days 36500)
>>  '(gnus-agent-mark-unread-after-downloaded nil)
>>
>> There are a couple of problems with this approach: e.g. I
>> have to run gnus-agent-regenerate a couple of times each day
>> since something gets out of whack, and the summary buffer
>> gets terribly confused at times and displays messages that
>> are just not there.
>>
>> I haven't had the time to look more closely at when these
>> problems occur, so I can't be more specific. I'm a lot less
>> happy with gnus since I started using the agent, though :(
>
> This is so sad :(.  It doesn't sound like your arrangement is worth
> the likely frustration.

Actually most people appear to be happy with the agent.  Niklas is
just one of an apparently small group that are having trouble.

Also Kai suggested that you check the manual for "unplugged" because your
config settings (i.e. (setq gnus-use-cache t)) has nothing to do with
the agent.  

The minimum that you should need to do is as follows:
1) In the group buffer, enter '^' to open the server buffer.
2) Move point to the server that you want to agentize.
3) Enter 'J a' to agentize the server.
4) Enter 'q' to return to the group buffer.
5) Open the group.
6) Select articles for downloading using '@'.  You should see a '%'
   mark appear next to each article.
7) Enter 'J u' to fetch the selected articles.
8) Read the manual as the agent can do quite a bit more than this.

Kevin

Re: nnimap usage model

[Kai Großjohann]

David Abrahams <dave@boost-consulting.com> writes:

> Wow, thanks for the fast reply, but it looks like you only read half
> of my message... or am I misunderstanding?

The second half was about the cache not working.  I think the Agent
will do what you want from the cache.

Or is it the first half that I should have been reading?  ;-)
-- 
A turnip curses Elvis

Re: nnimap usage model

[David Abrahams]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> Actually most people appear to be happy with the agent.  Niklas is
> just one of an apparently small group that are having trouble.
>
> Also Kai suggested that you check the manual for "unplugged" because your
> config settings (i.e. (setq gnus-use-cache t)) has nothing to do with
> the agent.  

Oh, I knew that, but I figured that GNUs had a single cache of
articles.  Maybe when you say "nothing to do with", you really mean
NOTHING to do with ;-)

> The minimum that you should need to do is as follows:
> 1) In the group buffer, enter '^' to open the server buffer.
> 2) Move point to the server that you want to agentize.
> 3) Enter 'J a' to agentize the server.
> 4) Enter 'q' to return to the group buffer.
> 5) Open the group.
> 6) Select articles for downloading using '@'.  You should see a '%'
>    mark appear next to each article.
> 7) Enter 'J u' to fetch the selected articles.
> 8) Read the manual as the agent can do quite a bit more than this.

Wow, combined with Niklas' formula this actually seems to be doing
something useful!

I had read up on Agent a while back when I had stock gnus that ships
with emacs, and either these are new features or I missed it or failed
to understand.

Time to study up again ;-)

Thanks for your attention, everyone.
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: nnimap usage model

[David Abrahams]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> David Abrahams <dave@boost-consulting.com> writes:
>
>> Wow, thanks for the fast reply, but it looks like you only read half
>> of my message... or am I misunderstanding?
>
> The second half was about the cache not working.  I think the Agent
> will do what you want from the cache.

...the light dawns...

> Or is it the first half that I should have been reading?  ;-)

No, my fault.  Apparently I've forgotten more than I once knew ;-)

Thanks for bearing with me,

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: nnimap usage model

[David Abrahams]

David Abrahams <dave@boost-consulting.com> writes:

> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>
>> The minimum that you should need to do is as follows:
>> 1) In the group buffer, enter '^' to open the server buffer.
>> 2) Move point to the server that you want to agentize.
>> 3) Enter 'J a' to agentize the server.
>> 4) Enter 'q' to return to the group buffer.
>> 5) Open the group.
>> 6) Select articles for downloading using '@'.  You should see a '%'
>>    mark appear next to each article.
>> 7) Enter 'J u' to fetch the selected articles.
>> 8) Read the manual as the agent can do quite a bit more than this.
>
> Wow, combined with Niklas' formula this actually seems to be doing
> something useful!

The really odd thing now is that all the articles I newly download
seem to be immediately marked as "ancient"; they show up weirdly
colored in the summary buffer.

Anybody have a clue why that could be?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: nnimap usage model

[Kevin Greiner]

David Abrahams <dave@boost-consulting.com> writes:

> David Abrahams <dave@boost-consulting.com> writes:
>
>> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>>
>>> The minimum that you should need to do is as follows:
>>> 1) In the group buffer, enter '^' to open the server buffer.
>>> 2) Move point to the server that you want to agentize.
>>> 3) Enter 'J a' to agentize the server.
>>> 4) Enter 'q' to return to the group buffer.
>>> 5) Open the group.
>>> 6) Select articles for downloading using '@'.  You should see a '%'
>>>    mark appear next to each article.
>>> 7) Enter 'J u' to fetch the selected articles.
>>> 8) Read the manual as the agent can do quite a bit more than this.
>>
>> Wow, combined with Niklas' formula this actually seems to be doing
>> something useful!

One word of warning. Setting gnus-agent-mark-unread-after-downloaded
to nil triggers a bug in the the agent.  I've checked-in a patch but
will need some early adopters to verify that it works for all.

> The really odd thing now is that all the articles I newly download
> seem to be immediately marked as "ancient"; they show up weirdly
> colored in the summary buffer.
>
> Anybody have a clue why that could be?

The agent has three faces and a format specifier to highlight articles
that have NOT been downloaded.  The faces appear by default while the
format specifier must be added through customization.

If you don't like using colors to indicate the undownloaded articles,
you can customize gnus-summary-highlight.  Just remove the three cons
cells that refer to gnus*undownloaded-face.

If you want to use +/- markers you can add %O to gnus-summary-line-format.

You're the first to describe newly downloaded articles as being marked
as "ancient".  Also that those articles are being highlighted.  Try
downloading the latest gnus-agent.el or set
gnus-agent-mark-unread-after-downloaded to t.

Kevin

Re: nnimap usage model

[David Abrahams]

Thanks for your reply, Kevin

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> The agent has three faces and a format specifier to highlight articles
> that have NOT been downloaded.  The faces appear by default while the
> format specifier must be added through customization.

Hmm, I'll see if I can track that down.  Could you elaborate on what
you mean by "appear by default", and where the customization for the
format specifier can be found?

> If you don't like using colors to indicate the undownloaded articles,
> you can customize gnus-summary-highlight.  Just remove the three cons
> cells that refer to gnus*undownloaded-face.
>
> If you want to use +/- markers you can add %O to gnus-summary-line-format.

I'll consider that as an alternative; it might be preferable.

> You're the first to describe newly downloaded articles as being marked
> as "ancient".  

I think I was mis-describing the marks; the face used for ancient
articles looks a lot like the one used for un-downloaded articles on
NTEmacs when you don't use Courier New :(

> Also that those articles are being highlighted.  

I don't think I ever mentioned the word "highlighted."

> Try downloading the latest gnus-agent.el or set
> gnus-agent-mark-unread-after-downloaded to t.

Well, now I'm seeing some other bizzarre behavior.  My relevant
settings are now:

    gnus-check-new-newsgroups nil
    gnus-total-expirable-newsgroups "INBOX"
    gnus-agent-cache t            ; see NOTE below
    gnus-agent t
    gnus-agent-consider-all-articles t
    gnus-agent-expire-days 36500
    gnus-agent-mark-unread-after-downloaded t

I was looking at my INBOX and I decided to see how many read messages
it was keeping, so I did `/ o 50' and the old messages appeared, but
suddenly all the messages which were marked already-read were now
marked undownloaded.  Does anybody have an explanation for that?

NOTE: also, I'm not really sure what I'm getting from
gnus-agent-cache.  All I can find in the documentation says "the agent
is also a big cache!"  Can somebody explain what that means?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: nnimap usage model

[Kevin Greiner]

David Abrahams <dave@boost-consulting.com> writes:

> Thanks for your reply, Kevin
>
> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>
>> The agent has three faces and a format specifier to highlight articles
>> that have NOT been downloaded.  The faces appear by default while the
>> format specifier must be added through customization.
>
> Hmm, I'll see if I can track that down.  Could you elaborate on what
> you mean by "appear by default", and where the customization for the
> format specifier can be found?

The variable gnus-summary-highlight controls how an article is
highlighted in the summary.  It contains a list of conditions and
faces over which Gnus will iterate to the first true condition
then select that face.  If you don't want to use faces to highlight
the undownloaded articles, you should customize gnus-summary-highlight
to delete the three cons cells that refer to the
gnus*undownloaded-face.

>
>> If you don't like using colors to indicate the undownloaded articles,
>> you can customize gnus-summary-highlight.  Just remove the three cons
>> cells that refer to gnus*undownloaded-face.
>>
>> If you want to use +/- markers you can add %O to gnus-summary-line-format.
>
> I'll consider that as an alternative; it might be preferable.
>
>> You're the first to describe newly downloaded articles as being marked
>> as "ancient".  
>
> I think I was mis-describing the marks; the face used for ancient
> articles looks a lot like the one used for un-downloaded articles on
> NTEmacs when you don't use Courier New :(

You can change the characters used by customizing
gnus-undownloaded-mark and gnus-downloaded-mark.  The +/- were
selected for historical reasons.

>
>> Also that those articles are being highlighted.  
>
> I don't think I ever mentioned the word "highlighted."
>
>> Try downloading the latest gnus-agent.el or set
>> gnus-agent-mark-unread-after-downloaded to t.
>
> Well, now I'm seeing some other bizzarre behavior.  My relevant
> settings are now:
>
>     gnus-check-new-newsgroups nil
>     gnus-total-expirable-newsgroups "INBOX"
>     gnus-agent-cache t            ; see NOTE below
>     gnus-agent t
>     gnus-agent-consider-all-articles t
>     gnus-agent-expire-days 36500
>     gnus-agent-mark-unread-after-downloaded t
>
> I was looking at my INBOX and I decided to see how many read messages
> it was keeping, so I did `/ o 50' and the old messages appeared, but
> suddenly all the messages which were marked already-read were now
> marked undownloaded.  Does anybody have an explanation for that?

Nope.  That's not something that I'm able to reproduce here.

> NOTE: also, I'm not really sure what I'm getting from
> gnus-agent-cache.  All I can find in the documentation says "the agent
> is also a big cache!"  Can somebody explain what that means?

It is an internal switch for temporarily disabling the agent.  You
should leave it set to t.  Gnus will bind it to nil as appropriate
times.

Kevin

Re: nnimap usage model

[Kai Großjohann]

David Abrahams <dave@boost-consulting.com> writes:

> NOTE: also, I'm not really sure what I'm getting from
> gnus-agent-cache.  All I can find in the documentation says "the agent
> is also a big cache!"  Can somebody explain what that means?

Well, after you do `J s' from the *Group* header, a lot of articles
end up on your local disk, under ~/News/agent.  Then you can do `J j'
in the *Group* buffer and then read news from your local disk.

-- 
A turnip curses Elvis

Re: nnimap usage model

[David Abrahams]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> David Abrahams <dave@boost-consulting.com> writes:
>
>> Thanks for your reply, Kevin
>>
>> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>>
>>> The agent has three faces and a format specifier to highlight articles
>>> that have NOT been downloaded.  The faces appear by default while the
>>> format specifier must be added through customization.
>>
>> Hmm, I'll see if I can track that down.  Could you elaborate on what
>> you mean by "appear by default", and where the customization for the
>> format specifier can be found?
>
> The variable gnus-summary-highlight controls how an article is
> highlighted in the summary.  It contains a list of conditions and
> faces over which Gnus will iterate to the first true condition
> then select that face.  If you don't want to use faces to highlight
> the undownloaded articles, you should customize gnus-summary-highlight
> to delete the three cons cells that refer to the
> gnus*undownloaded-face.

Yes, thanks, I understood all that from your previous postings; I
don't think it really answers my questions, though.  Should I rephrase
them?  I thought they were fairly precisely worded and I'm not sure I
can do better.

>>> If you don't like using colors to indicate the undownloaded articles,
>>> you can customize gnus-summary-highlight.  Just remove the three cons
>>> cells that refer to gnus*undownloaded-face.
>>>
>>> If you want to use +/- markers you can add %O to gnus-summary-line-format.
>>
>> I'll consider that as an alternative; it might be preferable.
>>
>>> You're the first to describe newly downloaded articles as being marked
>>> as "ancient".  
>>
>> I think I was mis-describing the marks; the face used for ancient
>> articles looks a lot like the one used for un-downloaded articles on
>> NTEmacs when you don't use Courier New :(
>
> You can change the characters used by customizing
> gnus-undownloaded-mark and gnus-downloaded-mark.  The +/- were
> selected for historical reasons.

I understand that; I wasn't using the article marks in my
summary-line-format; I was just referring to the face (i.e. colors)
used.

>> NOTE: also, I'm not really sure what I'm getting from
>> gnus-agent-cache.  All I can find in the documentation says "the agent
>> is also a big cache!"  Can somebody explain what that means?
>
> It is an internal switch for temporarily disabling the agent.  You
> should leave it set to t.  Gnus will bind it to nil as appropriate
> times.

Boy, that just makes it even more mysterious!

The "hate" part of my love-hate relationship with GNUs is mostly due
to not being able to get a clear and precise understanding of the
system architecture and consequently, how to make it do what I want.
I've tried to RTFM, which is imposing enough already.  I'd hate to
think that the only way to really understand things is to use the
source, Luke.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: nnimap usage model

[David Abrahams]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> David Abrahams <dave@boost-consulting.com> writes:
>
>> NOTE: also, I'm not really sure what I'm getting from
>> gnus-agent-cache.  All I can find in the documentation says "the agent
>> is also a big cache!"  Can somebody explain what that means?
>
> Well, after you do `J s' from the *Group* header, a lot of articles
> end up on your local disk, under ~/News/agent.  Then you can do `J j'
> in the *Group* buffer and then read news from your local disk.

That helps a bit, but I'm still in the dark.  If I had
gnus-agent-cache == nil (the default), I wouldn't be able to use 
`J s'?  Or what?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: nnimap usage model

[Kai Großjohann]

David Abrahams <dave@boost-consulting.com> writes:

> That helps a bit, but I'm still in the dark.  If I had
> gnus-agent-cache == nil (the default),

It seems that the default is t, not nil.

> I wouldn't be able to use `J s'?  Or what?

Well, err.  As I understand it, frobbing gnus-agent-cache influences
the behavior for the plugged case only.  So you could set
gnus-agent-cache to nil, then you could use `J s' to fetch articles
and headers.  But as long as you're online, Gnus won't use those
local copies when you enter a group and so on.  Instead, the headers
will be fetched again.  When you go unplugged, the local copies will
be used, of course -- Gnus can't use the remote ones, after all.

Suppose you're online.  You enter a group, then quit it, then enter
it again.

When gnus-agent-cache is nil, then Gnus will fetch headers from the
server, show the summary buffer.  Then you quit the summary.  Then
you enter it again and Gnus will fetch the headers from the server
again.

When gnus-agent-cache is t, then Gnus will fetch headers from the
server, then show the summary buffer.  Gnus will also store the
just-fetched headers locally.  Then after you exit and then re-enter
the group, Gnus will use the local copies of the headers, instead of
fetching them again.

I'm not sure whether Gnus will store the just-fetched headers locally
only when gnus-agent-cache is t, or whether this storing also happens
when gnus-agent-cache is nil.  Any expert out there?

Maybe the documentation should be improved.

-- 
A turnip curses Elvis

Re: nnimap usage model

[Kevin Greiner]

David Abrahams <dave@boost-consulting.com> writes:

> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>
>> David Abrahams <dave@boost-consulting.com> writes:
>>
>>> Thanks for your reply, Kevin
>>>
>>> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>>>
>>>> The agent has three faces and a format specifier to highlight articles
>>>> that have NOT been downloaded.  The faces appear by default while the
>>>> format specifier must be added through customization.
>>>
>>> Hmm, I'll see if I can track that down.  Could you elaborate on what
>>> you mean by "appear by default", and where the customization for the
>>> format specifier can be found?
>>
>> The variable gnus-summary-highlight controls how an article is
>> highlighted in the summary.  It contains a list of conditions and
>> faces over which Gnus will iterate to the first true condition
>> then select that face.  If you don't want to use faces to highlight
>> the undownloaded articles, you should customize gnus-summary-highlight
>> to delete the three cons cells that refer to the
>> gnus*undownloaded-face.
>
> Yes, thanks, I understood all that from your previous postings; I
> don't think it really answers my questions, though.  Should I rephrase
> them?  I thought they were fairly precisely worded and I'm not sure I
> can do better.

Well, "appear by default" is handled by the value of gnus-summary-highlight.
As for changing the format specifier, see gnus-undownloaded-mark below.

>
>>>> If you don't like using colors to indicate the undownloaded articles,
>>>> you can customize gnus-summary-highlight.  Just remove the three cons
>>>> cells that refer to gnus*undownloaded-face.
>>>>
>>>> If you want to use +/- markers you can add %O to gnus-summary-line-format.
>>>
>>> I'll consider that as an alternative; it might be preferable.
>>>
>>>> You're the first to describe newly downloaded articles as being marked
>>>> as "ancient".  
>>>
>>> I think I was mis-describing the marks; the face used for ancient
>>> articles looks a lot like the one used for un-downloaded articles on
>>> NTEmacs when you don't use Courier New :(
>>
>> You can change the characters used by customizing
>> gnus-undownloaded-mark and gnus-downloaded-mark.  The +/- were
>> selected for historical reasons.
>
> I understand that; I wasn't using the article marks in my
> summary-line-format; I was just referring to the face (i.e. colors)
> used.

Well, gnus-summary-highlight names the faces being used.  Once you
know the face, you can customize it with M-x customize-face.

>
>>> NOTE: also, I'm not really sure what I'm getting from
>>> gnus-agent-cache.  All I can find in the documentation says "the agent
>>> is also a big cache!"  Can somebody explain what that means?
>>
>> It is an internal switch for temporarily disabling the agent.  You
>> should leave it set to t.  Gnus will bind it to nil as appropriate
>> times.
>
> Boy, that just makes it even more mysterious!

Well, Kai's answer was much better.  It just goes to show that I
should stick to writing code.

>
> The "hate" part of my love-hate relationship with GNUs is mostly due
> to not being able to get a clear and precise understanding of the
> system architecture and consequently, how to make it do what I want.
> I've tried to RTFM, which is imposing enough already.  I'd hate to
> think that the only way to really understand things is to use the
> source, Luke.


Well, Dave, I'm not sure what manual you were using but from the
comments that you've made in this thread, something is wrong with it.
For example, you previously stated that the only documentation you
could find for gnus-agent-cache was "the agent is also a big cache!".
I just browsed the online info pages and found that "the agent is also
a big cache!" appears on '(gnus) Gnus Unplugged' where it is a
navigation link to the '(gnus) Agent as Cache' page.  On that page, I
found the following description:

  When Gnus is plugged, it is not efficient to download headers or
  articles from the server again, if they are already stored in the
  Agent.  So, Gnus normally only downloads headers once, and stores them
  in the Agent.  These headers are later used when generating the
  summary buffer, regardless of whether you are plugged or unplugged.
  Articles are not cached in the Agent by default though (that would
  potentially consume lots of disk space), but if you have already
  downloaded an article into the Agent, Gnus will not download the
  article from the server again but use the locally stored copy instead.
  
  This behaviour can be controlled by `gnus-agent-cache' (*Note Agent
  Variables::).

English is my first language and I admittedly had to read this twice.
However, the last part of the paragraph reiterates a rather concise
description of gnus-agent-cache: "if you have already downloaded an
article into the Agent, Gnus will not download the article from the
server again but use the locally stored copy instead.
  
This behaviour can be controlled by `gnus-agent-cache'"

This page also had a link to the '(gnus) Agent Variables' page where I
found:

`gnus-agent-cache' 
     Variable to control whether use the locally stored NOV and
     articles when plugged, e.g. essentially using the Agent as a
     cache.  The default is non-nil, which means to use the Agent as a
     cache.

Kevin

Re: nnimap usage model

[Kai Großjohann]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

>   When Gnus is plugged, it is not efficient to download headers or
>   articles from the server again, if they are already stored in the
>   Agent.  So, Gnus normally only downloads headers once, and stores them
>   in the Agent.  These headers are later used when generating the
>   summary buffer, regardless of whether you are plugged or unplugged.
>   Articles are not cached in the Agent by default though (that would
>   potentially consume lots of disk space), but if you have already
>   downloaded an article into the Agent, Gnus will not download the
>   article from the server again but use the locally stored copy instead.
>   
>   This behaviour can be controlled by `gnus-agent-cache' (*Note Agent
>   Variables::).
>
> English is my first language and I admittedly had to read this twice.

Well said.  :-)

Is the following correct?  Or rather, which parts of it are wrong?

Originally, the Agent was intended for offline reading: you download
headers and/or articles and then go offline and then Gnus uses the
locally stored data.  However, it turns out that the Agent is useful
even while you're online: it is usually faster to read headers and
articles from the local disk rather than from the network.
In that case, it's obviously useful to have some data on the local
disk in the first place.  But you don't want to have too much data on
the local disk, lest it burst.  So, what's a Gnus to do?

It turns out that the Gnus Towers decided that the following
compromise would be right for you.  However, Gnus is Gnus and thus
it goes without saying that you can configure this default behavior.

So, say that you enter a group and hence Gnus downloads the headers
for this group.  The default behavior is to store the headers locally.
So when you enter the group later on, the old headers can be fetched
from the local disk, and only the new headers have to be downloaded.
Good.  So what about articles?  Well, if an article happens to be on
the local disk already, Gnus will not fetch it from the network again
and instead use the local copy.  But on the other hand, Gnus does not
by default store every article you read on the local disk, as that
might consume too much disk space.

The previous description holds when the variable `gnus-agent-cache'
is non-nil, which is the default.  (*Note Agent Variables::).

If `gnus-agent-cache' is nil, then Gnus will not store headers or
articles locally, and it will not read locally stored headers or
articles.

    CCC: Kevin, Simon, is the previous paragraph correct?

Above, it was said that articles are not automatically stored locally
when you read them, while Gnus is plugged.  But what if I have a big
disk, you cry.  Don't worry!  You can use one of the following two
lines in ~/.emacs or ~/.gnus:

    (add-hook 'gnus-select-article-hook 'gnus-agent-fetch-selected-article)
    (add-hook 'gnus-mark-article-hook 'gnus-agent-fetch-selected-article)

It does not make sense to use both lines.  The difference between the
two lines is subtle.  The first line says, whenever you select an
article for reading, Gnus looks if it is on disk already, and if no,
then it is stored.  The second line says that Gnus only looks when you
select the article for the first time.

    CCC: Anyone, did I get the subtle difference right?  I kind of
    doubt it.  It's so subtle...

***

OK.  So much for the stuff that could be in that node of the info
file.  Now we need a better description of the variable
gnus-agent-cache.  I think the current description in `Agent
Variables' is misleading.  According to the description there, only
the reading is affected.  But I guess that also the storing of the
NOV data is affected.  Anyone?

-- 
A turnip curses Elvis

Re: nnimap usage model

[Kevin Greiner]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>
>>   When Gnus is plugged, it is not efficient to download headers or
>>   articles from the server again, if they are already stored in the
>>   Agent.  So, Gnus normally only downloads headers once, and stores them
>>   in the Agent.  These headers are later used when generating the
>>   summary buffer, regardless of whether you are plugged or unplugged.
>>   Articles are not cached in the Agent by default though (that would
>>   potentially consume lots of disk space), but if you have already
>>   downloaded an article into the Agent, Gnus will not download the
>>   article from the server again but use the locally stored copy instead.
>>   
>>   This behaviour can be controlled by `gnus-agent-cache' (*Note Agent
>>   Variables::).
>>
>> English is my first language and I admittedly had to read this twice.
>
> Well said.  :-)
>
> Is the following correct?  Or rather, which parts of it are wrong?
>
> Originally, the Agent was intended for offline reading: you download
> headers and/or articles and then go offline and then Gnus uses the
> locally stored data.  However, it turns out that the Agent is useful
> even while you're online: it is usually faster to read headers and
> articles from the local disk rather than from the network.
> In that case, it's obviously useful to have some data on the local
> disk in the first place.  But you don't want to have too much data on
> the local disk, lest it burst.  So, what's a Gnus to do?
>
> It turns out that the Gnus Towers decided that the following
> compromise would be right for you.  However, Gnus is Gnus and thus
> it goes without saying that you can configure this default behavior.
>
> So, say that you enter a group and hence Gnus downloads the headers
> for this group.  The default behavior is to store the headers locally.
> So when you enter the group later on, the old headers can be fetched
> from the local disk, and only the new headers have to be downloaded.
> Good.  So what about articles?  Well, if an article happens to be on
> the local disk already, Gnus will not fetch it from the network again
> and instead use the local copy.  But on the other hand, Gnus does not
> by default store every article you read on the local disk, as that
> might consume too much disk space.
>
> The previous description holds when the variable `gnus-agent-cache'
> is non-nil, which is the default.  (*Note Agent Variables::).
>
> If `gnus-agent-cache' is nil, then Gnus will not store headers or
> articles locally, and it will not read locally stored headers or
> articles.
>
>     CCC: Kevin, Simon, is the previous paragraph correct?

It's true so how does gnus-agent-cache differ from gnus-agent? hmmm,
see following...

When I search the code, I find that gnus-agent-cache always appears in
an AND expression, "(and gnus-agent gnus-agent-cache ...", that also
requires that gnus-agent be set.  The specific functions, as you
implied, where it is found are:

gnus-request-article-this-buffer
gnus-retrieve-headers
gnus-request-head
gnus-request-body
gnus-request-expire-articles
gnus-request-move-article

Checking further, the function gnus-agent-retrieve-headers is the only
function to bind gnus-agent-cache to nil.  This explains why the
original definition was somewhat accurate.  It also points out that
most of the functions checking gnus-agent-cache
(i.e. gnus-request-article-this-buffer, gnus-request-body,
gnus-request-expire-articles, and gnus-request-move-articles) should
NOT do so.  The only function called while gnus-agent-cache is bound
to nil is gnus-retrieve-headers.  That function performs an AND of
gnus-agent and gnus-agent-cache so binding either to nil would have
the same result.

I'd say that the proper thing to do is to replace gnus-agent-cache
with gnus-agent in gnus-agent-retrieve-headers (i.e. bind gnus-agent
to nil) then delete gnus-agent-cache at all other references.

If you really want to implement the original definition, then we'd
need to make several changes.  For headers, it would look something
like this: 
The function gnus-retrieve-headers would, if gnus-agent is
set, call gnus-agent-retrieve-headers which would, if gnus-agent-cache
is set or gnus-plugged is nil, use the local cache.  Otherwise,
gnus-agent-retrieve-headers would use the backend to retrieve the
headers then store them in the local cache.

As I see it, the only advantage to having gnus-agent-cache is to
handle the case in which the article keeps changing on the server.
Does that actually happen with any of the backends?



>
> Above, it was said that articles are not automatically stored locally
> when you read them, while Gnus is plugged.  But what if I have a big
> disk, you cry.  Don't worry!  You can use one of the following two
> lines in ~/.emacs or ~/.gnus:
>
>     (add-hook 'gnus-select-article-hook 'gnus-agent-fetch-selected-article)
>     (add-hook 'gnus-mark-article-hook 'gnus-agent-fetch-selected-article)
>
> It does not make sense to use both lines.  The difference between the
> two lines is subtle.  The first line says, whenever you select an
> article for reading, Gnus looks if it is on disk already, and if no,
> then it is stored.  The second line says that Gnus only looks when you
> select the article for the first time.

I'd change "The second line says that Gnus only looks when you select
the article for the first time." to "The second line says that Gnus
will fetch new articles to the local disk as the summary buffer is
opened.".

>
>     CCC: Anyone, did I get the subtle difference right?  I kind of
>     doubt it.  It's so subtle...
>
> ***
>
> OK.  So much for the stuff that could be in that node of the info
> file.  Now we need a better description of the variable
> gnus-agent-cache.  I think the current description in `Agent
> Variables' is misleading.  According to the description there, only
> the reading is affected.  But I guess that also the storing of the
> NOV data is affected.  Anyone?
>
> -- 
> A turnip curses Elvis

Kevin

Re: nnimap usage model

[Andreas Fuchs]

On 2003-02-16, Kai Großjohann <kai.grossjohann@uni-duisburg.de> wrote:
> Above, it was said that articles are not automatically stored locally
> when you read them, while Gnus is plugged.  But what if I have a big
> disk, you cry.  Don't worry!  You can use one of the following two
> lines in ~/.emacs or ~/.gnus:
> 
> (add-hook 'gnus-select-article-hook 'gnus-agent-fetch-selected-article)

Humm. This makes the "selected" face in the summary buffer disappear
from an article when I select it for reading and it gets fetched from
the server into the agent..

> (add-hook 'gnus-mark-article-hook 'gnus-agent-fetch-selected-article)

This makes ticked (but not yet stored in the agent) articles be
unticked and marked as "R" when I first select them and they are
stored. Strange behaviour.

Anyway, interesting advice.
-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs
irc.freenode.net's #emacs - online emacs advice from IRC addicts

Re: nnimap usage model

[Kai Großjohann]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> It's true so how does gnus-agent-cache differ from gnus-agent? hmmm,
> see following...
>
> When I search the code, I find that gnus-agent-cache always appears in
> an AND expression, "(and gnus-agent gnus-agent-cache ...", that also
> requires that gnus-agent be set.  The specific functions, as you
> implied, where it is found are:
>
> gnus-request-article-this-buffer
> gnus-retrieve-headers
> gnus-request-head
> gnus-request-body
> gnus-request-expire-articles
> gnus-request-move-article
>
> Checking further, the function gnus-agent-retrieve-headers is the only
> function to bind gnus-agent-cache to nil.  This explains why the
> original definition was somewhat accurate.  It also points out that
> most of the functions checking gnus-agent-cache
> (i.e. gnus-request-article-this-buffer, gnus-request-body,
> gnus-request-expire-articles, and gnus-request-move-articles) should
> NOT do so.  The only function called while gnus-agent-cache is bound
> to nil is gnus-retrieve-headers.  That function performs an AND of
> gnus-agent and gnus-agent-cache so binding either to nil would have
> the same result.
>
> I'd say that the proper thing to do is to replace gnus-agent-cache
> with gnus-agent in gnus-agent-retrieve-headers (i.e. bind gnus-agent
> to nil) then delete gnus-agent-cache at all other references.
>
> If you really want to implement the original definition, then we'd
> need to make several changes.  For headers, it would look something
> like this: 
> The function gnus-retrieve-headers would, if gnus-agent is
> set, call gnus-agent-retrieve-headers which would, if gnus-agent-cache
> is set or gnus-plugged is nil, use the local cache.  Otherwise,
> gnus-agent-retrieve-headers would use the backend to retrieve the
> headers then store them in the local cache.
>
> As I see it, the only advantage to having gnus-agent-cache is to
> handle the case in which the article keeps changing on the server.
> Does that actually happen with any of the backends?

Now I'm more confused than before.

Often, gnus-agent and gnus-agent-cache are mentioned together.  There
is one spot that you have identified where gnus-agent-cache is
mentioned without gnus-agent.

There are also just a couple of spots where gnus-agent is mentioned
without gnus-agent-cache: (1) On sending a message, the Gcc processing
is different depending on gnus-agent.  (2) gnus-get-unread-articles
tells the agent to save the active file, if gnus-agent is non-nil.
(3) gnus-active-to-gnus-format does the same.

Hm.  Oh, I forgot to search for "gnus-agent$".  That finds more
spots.  (1) gnus-group-get-new-news-this-group tells the agent to
save the group info.  (2) gnus-get-function calls gnus-agent
functions instead of nnchoke functions.  (3) gnus-open-server does
stuff.  ...  And other stuff.

So, to summarize:

* Turning on gnus-agent enables a lot of special behavior, even if
  gnus-agent-cache is off.

* Turning on both gnus-agent and gnus-agent-cache enables more
  special behavior.

* Turning on gnus-agent-cache enables 1 piece of strange
  functionality, even if gnus-agent is off.  This is arguably a bug.
  Hm.  Hmmm...  No, the let-binding that you're talking about is
  something else entirely.

I think what we want is this:

* If gnus-agent is off, then the value of gnus-agent-cache doesn't
  matter.

* If gnus-agent is on, then it's possible to also turn on
  gnus-agent-cache to enable more special behavior.


It seems there is a misunderstanding.  I'm looking at things from the
user's perspective.  For this case, I think the questions we need to
answer are the following:

(1) Under which circumstances does the agent write data to the local
    disk?  Which data does it write?

(2) Under which circumstances does the agent read data from the local
    disk?  Which data does it read?

Then we can formulate some documentation that helps the user.

Another issue is whether the current Gnus behavior is correct or
should it be changed.
-- 
A turnip curses Elvis

Re: nnimap usage model

[Kai Großjohann]

Andreas Fuchs <asf@void.at> writes:

> On 2003-02-16, Kai Großjohann <kai.grossjohann@uni-duisburg.de> wrote:
>> Above, it was said that articles are not automatically stored locally
>> when you read them, while Gnus is plugged.  But what if I have a big
>> disk, you cry.  Don't worry!  You can use one of the following two
>> lines in ~/.emacs or ~/.gnus:
>> 
>> (add-hook 'gnus-select-article-hook 'gnus-agent-fetch-selected-article)
>
> Humm. This makes the "selected" face in the summary buffer disappear
> from an article when I select it for reading and it gets fetched from
> the server into the agent..

The "selected" face?  You mean the "undownloaded" face?

But otherwise, this appears to be the desired behavior.

>> (add-hook 'gnus-mark-article-hook 'gnus-agent-fetch-selected-article)
>
> This makes ticked (but not yet stored in the agent) articles be
> unticked and marked as "R" when I first select them and they are
> stored. Strange behaviour.

This is strange indeed.  Especially since gnus-select-article-hook is
supposed to run every time you select an article, and
gnus-mark-article-hook only sometimes.  So why does
gnus-mark-article-hook do more when you select ticked articles than
gnus-select-article-hook?

Weird.

> Anyway, interesting advice.

-- 
A turnip curses Elvis

Re: nnimap usage model

[Andreas Fuchs]

Today, Kai Großjohann <kai.grossjohann@uni-duisburg.de> wrote:
>>> (add-hook 'gnus-select-article-hook
>>> 'gnus-agent-fetch-selected-article)
>>
>> Humm. This makes the "selected" face in the summary buffer disappear
>> from an article when I select it for reading and it gets fetched from
>> the server into the agent..
> 
> The "selected" face?  You mean the "undownloaded" face?

Right. It happens like this:

Select an unseen/undownloaded article for the first time:
* [gnus is doing stuff...]
* article buffer gets set up
* article line (the part that is usually highlighted with
  gnus-summary-selected-face) in the summary buffer bears the `nil'
  face (seen via M-x describe-face).

Select an article that was downloaded before:
* [gnus is doing stuff...]
* article buffer gets set up
* article line bears the gnus-summary-selected-face.

Strange.

>> This makes ticked (but not yet stored in the agent) articles be
>> unticked and marked as "R" when I first select them and they are
>> stored. Strange behaviour.
> 
> This is strange indeed.  Especially since gnus-select-article-hook is
> supposed to run every time you select an article, and
> gnus-mark-article-hook only sometimes.  So why does
> gnus-mark-article-hook do more when you select ticked articles than
> gnus-select-article-hook?
> 
> Weird.

Yeah. Might be that I tested it the wrong way. (-;

Thanks,
-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs
irc.freenode.net's #emacs - online emacs advice from IRC addicts

Re: nnimap usage model

[Kevin Greiner]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>
>> It's true so how does gnus-agent-cache differ from gnus-agent? hmmm,
>> see following...
>>
>> When I search the code, I find that gnus-agent-cache always appears in
>> an AND expression, "(and gnus-agent gnus-agent-cache ...", that also
>> requires that gnus-agent be set.  The specific functions, as you
>> implied, where it is found are:
>>
>> gnus-request-article-this-buffer
>> gnus-retrieve-headers
>> gnus-request-head
>> gnus-request-body
>> gnus-request-expire-articles
>> gnus-request-move-article
>>
>> Checking further, the function gnus-agent-retrieve-headers is the only
>> function to bind gnus-agent-cache to nil.  This explains why the
>> original definition was somewhat accurate.  It also points out that
>> most of the functions checking gnus-agent-cache
>> (i.e. gnus-request-article-this-buffer, gnus-request-body,
>> gnus-request-expire-articles, and gnus-request-move-articles) should
>> NOT do so.  The only function called while gnus-agent-cache is bound
>> to nil is gnus-retrieve-headers.  That function performs an AND of
>> gnus-agent and gnus-agent-cache so binding either to nil would have
>> the same result.
>>
>> I'd say that the proper thing to do is to replace gnus-agent-cache
>> with gnus-agent in gnus-agent-retrieve-headers (i.e. bind gnus-agent
>> to nil) then delete gnus-agent-cache at all other references.
>>
>> If you really want to implement the original definition, then we'd
>> need to make several changes.  For headers, it would look something
>> like this: 
>> The function gnus-retrieve-headers would, if gnus-agent is
>> set, call gnus-agent-retrieve-headers which would, if gnus-agent-cache
>> is set or gnus-plugged is nil, use the local cache.  Otherwise,
>> gnus-agent-retrieve-headers would use the backend to retrieve the
>> headers then store them in the local cache.
>>
>> As I see it, the only advantage to having gnus-agent-cache is to
>> handle the case in which the article keeps changing on the server.
>> Does that actually happen with any of the backends?
>
> Now I'm more confused than before.
>
> Often, gnus-agent and gnus-agent-cache are mentioned together.  There
> is one spot that you have identified where gnus-agent-cache is
> mentioned without gnus-agent.
>
> There are also just a couple of spots where gnus-agent is mentioned
> without gnus-agent-cache: (1) On sending a message, the Gcc processing
> is different depending on gnus-agent.  (2) gnus-get-unread-articles
> tells the agent to save the active file, if gnus-agent is non-nil.
> (3) gnus-active-to-gnus-format does the same.
>
> Hm.  Oh, I forgot to search for "gnus-agent$".  That finds more
> spots.  (1) gnus-group-get-new-news-this-group tells the agent to
> save the group info.  (2) gnus-get-function calls gnus-agent
> functions instead of nnchoke functions.  (3) gnus-open-server does
> stuff.  ...  And other stuff.
>
> So, to summarize:
>
> * Turning on gnus-agent enables a lot of special behavior, even if
>   gnus-agent-cache is off.
>
> * Turning on both gnus-agent and gnus-agent-cache enables more
>   special behavior.
>
> * Turning on gnus-agent-cache enables 1 piece of strange
>   functionality, even if gnus-agent is off.  This is arguably a bug.
>   Hm.  Hmmm...  No, the let-binding that you're talking about is
>   something else entirely.
>
> I think what we want is this:
>
> * If gnus-agent is off, then the value of gnus-agent-cache doesn't
>   matter.
>
> * If gnus-agent is on, then it's possible to also turn on
>   gnus-agent-cache to enable more special behavior.
>
>
> It seems there is a misunderstanding.  I'm looking at things from the
> user's perspective.  For this case, I think the questions we need to
> answer are the following:
>
> (1) Under which circumstances does the agent write data to the local
>     disk?  Which data does it write?
>
> (2) Under which circumstances does the agent read data from the local
>     disk?  Which data does it read?
>
> Then we can formulate some documentation that helps the user.
>
> Another issue is whether the current Gnus behavior is correct or
> should it be changed.

I don't see these as being separate issues.  If the current
implementation is broken, and no one has noticed, then the feature
must not be in wide spread use.  If it isn't used, do we document how
we think it should work (then fix the implementation) or do we remove
the feature from the documentation?  On the other hand, if the current
implementation is working, how can we document it correctly if we
can't agree on what it is doing?

Kevin

Re: nnimap usage model

[Kai Großjohann]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:
>
>> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>>
>>> I'd say that the proper thing to do is to replace gnus-agent-cache
>>> with gnus-agent in gnus-agent-retrieve-headers (i.e. bind gnus-agent
>>> to nil) then delete gnus-agent-cache at all other references.
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>> [...]
>>
>> It seems there is a misunderstanding.  I'm looking at things from the
>> user's perspective.  For this case, I think the questions we need to
>> answer are the following:
>>
>> (1) Under which circumstances does the agent write data to the local
>>     disk?  Which data does it write?
>>
>> (2) Under which circumstances does the agent read data from the local
>>     disk?  Which data does it read?
>>
>> Then we can formulate some documentation that helps the user.
>>
>> Another issue is whether the current Gnus behavior is correct or
>> should it be changed.
>
> I don't see these as being separate issues.  If the current
> implementation is broken, and no one has noticed, then the feature
> must not be in wide spread use.  If it isn't used, do we document how
> we think it should work (then fix the implementation) or do we remove
> the feature from the documentation?  On the other hand, if the current
> implementation is working, how can we document it correctly if we
> can't agree on what it is doing?

Ah, I think I missed the crucial part: you were suggesting to
eliminate the variable gnus-agent-cache entirely.  *blush*

So, is anyone using the combination of gnus-agent being t but
gnus-agent-cache being nil?

I think now I agree with your suggestion of just removing the
variable gnus-agent-cache.

I must spend more time to grok Kevin's postings.
I must spend more time to grok Kevin's postings.
I must spend more time to grok Kevin's postings.
I must spend more time to grok Kevin's postings.

-- 
A turnip curses Elvis

Re: nnimap usage model

[Simon Josefsson]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> So, is anyone using the combination of gnus-agent being t but
> gnus-agent-cache being nil?
>
> I think now I agree with your suggestion of just removing the
> variable gnus-agent-cache.

Making it possible to revert to old behaviour is IMHO always good, but
if it means alot of work maybe it can be removed...  the GNUS-NEWS
entry should be changed though:

,----
| ** Gnus reads the NOV and articles in the Agent if plugged.
|
| If one reads an article while plugged, and the article already exists
| in the Agent, it won't get downloaded once more.  (setq
| gnus-agent-cache nil) reverts to the old behavior.
`----

OTOH, it doesn't sound like it would generate much work to call the
backend directly instead of looking at the cache directory of
gnus-agent-cache is null?

Re: nnimap usage model

[David Abrahams]

First I just want to thank you guys for your responsiveness and the
attention you've given to this issue...

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> David Abrahams <dave@boost-consulting.com> writes:
>
>> That helps a bit, but I'm still in the dark.  If I had
>> gnus-agent-cache == nil (the default),
>
> It seems that the default is t, not nil.

Whoops.

>> I wouldn't be able to use `J s'?  Or what?
>
> Well, err.  As I understand it, frobbing gnus-agent-cache influences

Sorry: frobbing?

> the behavior for the plugged case only.  So you could set
> gnus-agent-cache to nil, then you could use `J s' to fetch articles
> and headers.  But as long as you're online, Gnus won't use those
> local copies when you enter a group and so on.  Instead, the headers
> will be fetched again.  

Seems rather pointless, doesn't it?

> When you go unplugged, the local copies will be used, of course --
> Gnus can't use the remote ones, after all.
>
> Suppose you're online.  You enter a group, then quit it, then enter
> it again.
>
> When gnus-agent-cache is nil, then Gnus will fetch headers from the
> server, show the summary buffer.  Then you quit the summary.  Then
> you enter it again and Gnus will fetch the headers from the server
> again.
>
> When gnus-agent-cache is t, then Gnus will fetch headers from the
> server, then show the summary buffer.  Gnus will also store the
> just-fetched headers locally.  Then after you exit and then re-enter
> the group, Gnus will use the local copies of the headers, instead of
> fetching them again.

That sounds like what I want.

> I'm not sure whether Gnus will store the just-fetched headers locally
> only when gnus-agent-cache is t, or whether this storing also happens
> when gnus-agent-cache is nil.  Any expert out there?
>
> Maybe the documentation should be improved.

Thanks again for looking at this.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: nnimap usage model

[Kai Großjohann]

David Abrahams <dave@boost-consulting.com> writes:

> kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:
>
>> Well, err.  As I understand it, frobbing gnus-agent-cache influences
>
> Sorry: frobbing?

It's hacker jargon.  It means something like toggle: to frob a light
switch.  For details, see the jargon file (can be found via Google).

>> the behavior for the plugged case only.  So you could set
>> gnus-agent-cache to nil, then you could use `J s' to fetch articles
>> and headers.  But as long as you're online, Gnus won't use those
>> local copies when you enter a group and so on.  Instead, the headers
>> will be fetched again.  
>
> Seems rather pointless, doesn't it?

You'd be surprised.  Some people have uses for things that mere
mortals (like me) can't imagine.  Maybe somebody is running Emacs with
an NFS mounted home dir on a slow link where the server is on a faster
link.  Whatever...

But it's also the case that I fundamentally don't understand what Gnus
is doing -- see the discussion between Kevin and me regarding this.
-- 
A preposition is not a good thing to end a sentence with.

Re: nnimap usage model

[Kevin Greiner]

Simon Josefsson <jas@extundo.com> writes:

> kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:
>
>> So, is anyone using the combination of gnus-agent being t but
>> gnus-agent-cache being nil?
>>
>> I think now I agree with your suggestion of just removing the
>> variable gnus-agent-cache.
>
> Making it possible to revert to old behaviour is IMHO always good, but
> if it means alot of work maybe it can be removed...  the GNUS-NEWS
> entry should be changed though:
>
> ,----
> | ** Gnus reads the NOV and articles in the Agent if plugged.
> |
> | If one reads an article while plugged, and the article already exists
> | in the Agent, it won't get downloaded once more.  (setq
> | gnus-agent-cache nil) reverts to the old behavior.
> `----
>
> OTOH, it doesn't sound like it would generate much work to call the
> backend directly instead of looking at the cache directory of
> gnus-agent-cache is null?

If we did that, then setting gnus-agent-cache to null is identical to
setting gnus-agent to null.

As I read it, setting gnus-agent-cache to null will result in the
agent always fetching headers and articles from the server that it
then stores locally.

Kai had a good point concerning performance. My thoughts were that
this was a useful setting back when the agent wasn't that reliable.
If you don't trust the agent, you might be willing to let it cache
articles.  However, you would not want to depend on those cached
articles when the server was available.

What I need to do is stop talking and start testing.

Kevin

gnus-agent-cache is broken

[Kevin Greiner]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:
>>
>>> So, is anyone using the combination of gnus-agent being t but
>>> gnus-agent-cache being nil?
>>>
>>> I think now I agree with your suggestion of just removing the
>>> variable gnus-agent-cache.
>>
>> Making it possible to revert to old behaviour is IMHO always good, but
>> if it means alot of work maybe it can be removed...  the GNUS-NEWS
>> entry should be changed though:
>>
>> ,----
>> | ** Gnus reads the NOV and articles in the Agent if plugged.
>> |
>> | If one reads an article while plugged, and the article already exists
>> | in the Agent, it won't get downloaded once more.  (setq
>> | gnus-agent-cache nil) reverts to the old behavior.
>> `----
>>
>> OTOH, it doesn't sound like it would generate much work to call the
>> backend directly instead of looking at the cache directory of
>> gnus-agent-cache is null?
>
> If we did that, then setting gnus-agent-cache to null is identical to
> setting gnus-agent to null.
>
> As I read it, setting gnus-agent-cache to null will result in the
> agent always fetching headers and articles from the server that it
> then stores locally.
>
> Kai had a good point concerning performance. My thoughts were that
> this was a useful setting back when the agent wasn't that reliable.
> If you don't trust the agent, you might be willing to let it cache
> articles.  However, you would not want to depend on those cached
> articles when the server was available.
>
> What I need to do is stop talking and start testing.

OK, it failed my very first test.  I set gnus-agent-cache to nil then
opened a group.  All of the new headers were fetched as expected.
However, they were NOT stored in .overview.

I'll see what I can do to make it work.

Kevin

FIXED: gnus-agent-cache

[Kevin Greiner]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>
>> Simon Josefsson <jas@extundo.com> writes:
>>
>>> kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:
>>>
>>>> So, is anyone using the combination of gnus-agent being t but
>>>> gnus-agent-cache being nil?
>>>>
>>>> I think now I agree with your suggestion of just removing the
>>>> variable gnus-agent-cache.
>>>
>>> Making it possible to revert to old behaviour is IMHO always good, but
>>> if it means alot of work maybe it can be removed...  the GNUS-NEWS
>>> entry should be changed though:
>>>
>>> ,----
>>> | ** Gnus reads the NOV and articles in the Agent if plugged.
>>> |
>>> | If one reads an article while plugged, and the article already exists
>>> | in the Agent, it won't get downloaded once more.  (setq
>>> | gnus-agent-cache nil) reverts to the old behavior.
>>> `----
>>>
>>> OTOH, it doesn't sound like it would generate much work to call the
>>> backend directly instead of looking at the cache directory of
>>> gnus-agent-cache is null?
>>
>> If we did that, then setting gnus-agent-cache to null is identical to
>> setting gnus-agent to null.
>>
>> As I read it, setting gnus-agent-cache to null will result in the
>> agent always fetching headers and articles from the server that it
>> then stores locally.
>>
>> Kai had a good point concerning performance. My thoughts were that
>> this was a useful setting back when the agent wasn't that reliable.
>> If you don't trust the agent, you might be willing to let it cache
>> articles.  However, you would not want to depend on those cached
>> articles when the server was available.
>>
>> What I need to do is stop talking and start testing.
>
> OK, it failed my very first test.  I set gnus-agent-cache to nil then
> opened a group.  All of the new headers were fetched as expected.
> However, they were NOT stored in .overview.
>
> I'll see what I can do to make it work.

gnus-agent-cache should now work as the documentation appears to
define it.  If you clear gnus-agent-cache, the plugged behavior is
changed such that all requests are ALWAYS sent to the server.  The
response to each request is still cached in the agent (for future
unplugged usage).

Kevin