Summary buffer highlighting

Summary buffer highlighting

[Emerick Rogul]

Has something changed in the summary buffer highlighting in the past
week?  It seems that all of the headers in my summary buffers are now
being shown in inverse video.  I'm running the latest version of ding
in an Emacs 21.1.1 terminal session.  I haven't changed anything in my
config files, this just seems to have started in the past few days.

-Emerick
-- 
-------------------------------------------------------------------------
Emerick Rogul             /\/     "how young are you, how old am i?
emerick@cs.bu.edu         /\/      let's count the rings around my eyes."
------------------------------------------------- 'i will dare', the mats

automatic Agentizing of servers (was: Summary buffer highlighting)

[Ted Zlatanov]

On Mon, 24 Nov 2003, emerick@cs.bu.edu wrote:

> Has something changed in the summary buffer highlighting in the past
> week?  It seems that all of the headers in my summary buffers are
> now being shown in inverse video.  I'm running the latest version of
> ding in an Emacs 21.1.1 terminal session.  I haven't changed
> anything in my config files, this just seems to have started in the
> past few days.

I noticed the Agent is enabled by default for nnimap now, which may
cause the highlighting problems you notice.  Check the Server buffer
(^ from the Group buffer).

To Agent developers: maybe I'm missing something, but if I explicitly
remove a server from the Agent (which I've done for my nnimap server
before and I also did yesterday) should that server be agentized again
when I start Gnus?  That's what happened this morning.

Thanks
Ted

Re: automatic Agentizing of servers (was: Summary buffer

[Emerick Rogul]

Ted Zlatanov writes:

> I noticed the Agent is enabled by default for nnimap now, which may
> cause the highlighting problems you notice.

Yes, that's definitely what's causing the problem.  I set gnus-agent
to nil just now and the highlighting went away.  Is this highlighting
expected behavior or is there a bug in the agent code?

Anyway, thanks for the tip on where to look -- I was going
video-blind!

-Emerick
-- 
-------------------------------------------------------------------------
Emerick Rogul             /\/     "how young are you, how old am i?
emerick@cs.bu.edu         /\/      let's count the rings around my eyes."
------------------------------------------------- 'i will dare', the mats

Re: automatic Agentizing of servers (was: Summary buffer

[Kevin Greiner]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Mon, 24 Nov 2003, emerick@cs.bu.edu wrote:
>
>> Has something changed in the summary buffer highlighting in the past
>> week?  It seems that all of the headers in my summary buffers are
>> now being shown in inverse video.  I'm running the latest version of
>> ding in an Emacs 21.1.1 terminal session.  I haven't changed
>> anything in my config files, this just seems to have started in the
>> past few days.
>
> I noticed the Agent is enabled by default for nnimap now, which may
> cause the highlighting problems you notice.  Check the Server buffer
> (^ from the Group buffer).

Well, first the agent doesn't enable inverse video.  It changes the
header's foreground color to cyan (unless you changed that
locally).  So, it is possible that this entire discussion will not
apply.

The highlighting should only occur if you have both enabled the agent
(now the default) AND agentized the servers.  If you are truely using
the latest version of gnus from CVS, you may have been effected by the
latest bug fix.  The agent had a bug whereby editing a method's
configuration could result in it being unagentized.  That's because
the agent was failing to find an exact match when it compared the old
and new methods.  It gets to be a rather long story but the patch
prevents, and corrects, this sort of problem.  So, if the old gnus
unagentized some of your servers then the new gnus could have reversed
that error to make then agentized again.

BTW, the nnimap developers turned the agent on to provide client-side
caching.  Rather than turning that off, you might want to consider
turning off the undownloaded faces.  You can do that by locally
editing the faces (gnus-summary-*-undownloaded-face) to mimic the
normal faces or setting the agent-disable-undownloaded-faces parameter
(See the manual for all of the locations where agent parameters can be
set).

> To Agent developers: maybe I'm missing something, but if I explicitly
> remove a server from the Agent (which I've done for my nnimap server
> before and I also did yesterday) should that server be agentized again
> when I start Gnus?  That's what happened this morning.

No, that shouldn't happen.  The latest patch changing the agent
occurred on 20 Nov 2003.  Have you updated from CVS since then?  Can
you check the contents of agent/lib/servers?  Does it appear to be
list of methods or is it a list of server names?

Kevin

Re: automatic Agentizing of servers (was: Summary buffer

[Emerick Rogul]

Kevin Greiner writes:

> Well, first the agent doesn't enable inverse video.  It changes the
> header's foreground color to cyan (unless you changed that
> locally).

Actually, notice the final clause in this (and the other defface's for
gnus-summary-*-downloaded-face):

(defface gnus-summary-normal-undownloaded-face
   '((((class color)
       (background light))
      (:foreground "cyan4" :bold nil))
     (((class color) (background dark))
      (:foreground "LightGray" :bold nil))
     (t (:inverse-video t)))
  "Face used for normal interest uncached articles.")

Personally, I find this setting to be a serious eye strain and I would
argue against it being the default.  But at least now I understand
what settings I need to twiddle to disable it.

-Emerick
-- 
-------------------------------------------------------------------------
Emerick Rogul             /\/     "how young are you, how old am i?
emerick@cs.bu.edu         /\/      let's count the rings around my eyes."
------------------------------------------------- 'i will dare', the mats

Re: automatic Agentizing of servers (was: Summary buffer

[Ted Zlatanov]

On Mon, 24 Nov 2003, kgreiner@xpediantsolutions.com wrote:

> The highlighting should only occur if you have both enabled the
> agent (now the default) AND agentized the servers.  If you are
> truely using the latest version of gnus from CVS, you may have been
> effected by the latest bug fix.  The agent had a bug whereby editing
> a method's configuration could result in it being unagentized.
> That's because the agent was failing to find an exact match when it
> compared the old and new methods.  It gets to be a rather long story
> but the patch prevents, and corrects, this sort of problem.  So, if
> the old gnus unagentized some of your servers then the new gnus
> could have reversed that error to make then agentized again.

I have the agent enabled (gnus-agent is t).  No servers were agentized
when I quit Gnus.  My nnimap server was agentized when I started Gnus.
I would like to keep gnus-agent t, without automatic agentizing of any
of my servers.  I have not edited any server method configurations.

I use the latest CVS, updated nightly, and I made sure I was up to
date before restarting Gnus.

> BTW, the nnimap developers turned the agent on to provide
> client-side caching.  Rather than turning that off, you might want
> to consider turning off the undownloaded faces.  You can do that by
> locally editing the faces (gnus-summary-*-undownloaded-face) to
> mimic the normal faces or setting the
> agent-disable-undownloaded-faces parameter (See the manual for all
> of the locations where agent parameters can be set).

As far as the faces go, that's great.  My problem is that I can't use
the agent because my disk quota is very low.  Also, when quitting a
summary buffer the Agent's checks are slow (10x slower than without
the Agent) but that's not the main problem.

> Ted Zlatanov <tzz@lifelogs.com> writes:
>> To Agent developers: maybe I'm missing something, but if I
>> explicitly remove a server from the Agent (which I've done for my
>> nnimap server before and I also did yesterday) should that server
>> be agentized again when I start Gnus?  That's what happened this
>> morning.
> 
> No, that shouldn't happen.  The latest patch changing the agent
> occurred on 20 Nov 2003.  Have you updated from CVS since then?  Can
> you check the contents of agent/lib/servers?  Does it appear to be
> list of methods or is it a list of server names?

~/News/agent/lib/servers contains the string "nil".  Still, my nnimap
server was agentized when I restarted Gnus just now.  By restart, I
mean a full Emacs exit and start again.  I'm using the CVS Emacs.

Thanks
Ted

Re: automatic Agentizing of servers (was: Summary buffer

[Kevin Greiner]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Mon, 24 Nov 2003, kgreiner@xpediantsolutions.com wrote:
>
>> The highlighting should only occur if you have both enabled the
>> agent (now the default) AND agentized the servers.  If you are
>> truely using the latest version of gnus from CVS, you may have been
>> effected by the latest bug fix.  The agent had a bug whereby editing
>> a method's configuration could result in it being unagentized.
>> That's because the agent was failing to find an exact match when it
>> compared the old and new methods.  It gets to be a rather long story
>> but the patch prevents, and corrects, this sort of problem.  So, if
>> the old gnus unagentized some of your servers then the new gnus
>> could have reversed that error to make then agentized again.
>
> I have the agent enabled (gnus-agent is t).  No servers were agentized
> when I quit Gnus.  My nnimap server was agentized when I started Gnus.
> I would like to keep gnus-agent t, without automatic agentizing of any
> of my servers.  I have not edited any server method configurations.
>
> I use the latest CVS, updated nightly, and I made sure I was up to
> date before restarting Gnus.

I've traced this behavior to the gnus-agent-auto-agentize-methods
variable.  If you don't agentize ANY server, the methods named in this
variable (currently nntp and nnimap) will be agentized by gnus when
you start up.  Perhaps we can make this customizable or only apply it
when the agent is being used for the first time (for example, when
agent/lib/servers doesn't exist).  I'd rather defer this to the
original author since I'm not aware of the requirements behind adding it.

>> BTW, the nnimap developers turned the agent on to provide
>> client-side caching.  Rather than turning that off, you might want
>> to consider turning off the undownloaded faces.  You can do that by
>> locally editing the faces (gnus-summary-*-undownloaded-face) to
>> mimic the normal faces or setting the
>> agent-disable-undownloaded-faces parameter (See the manual for all
>> of the locations where agent parameters can be set).
>
> As far as the faces go, that's great.  My problem is that I can't use
> the agent because my disk quota is very low.  Also, when quitting a
> summary buffer the Agent's checks are slow (10x slower than without
> the Agent) but that's not the main problem.

The disk quote I can understand.  I'm not sure about the agent checks.
Right now, I don't remember the agent doing anything when quitting a
summary buffer.

>> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> To Agent developers: maybe I'm missing something, but if I
>>> explicitly remove a server from the Agent (which I've done for my
>>> nnimap server before and I also did yesterday) should that server
>>> be agentized again when I start Gnus?  That's what happened this
>>> morning.
>> 
>> No, that shouldn't happen.  The latest patch changing the agent
>> occurred on 20 Nov 2003.  Have you updated from CVS since then?  Can
>> you check the contents of agent/lib/servers?  Does it appear to be
>> list of methods or is it a list of server names?
>
> ~/News/agent/lib/servers contains the string "nil".  Still, my nnimap
> server was agentized when I restarted Gnus just now.  By restart, I
> mean a full Emacs exit and start again.  I'm using the CVS Emacs.

See comments above concerning gnus-agent-auto-agentize-methods.

Kevin

Re: automatic Agentizing of servers (was: Summary buffer

[Simon Josefsson]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> On Mon, 24 Nov 2003, kgreiner@xpediantsolutions.com wrote:
>>
>>> The highlighting should only occur if you have both enabled the
>>> agent (now the default) AND agentized the servers.  If you are
>>> truely using the latest version of gnus from CVS, you may have been
>>> effected by the latest bug fix.  The agent had a bug whereby editing
>>> a method's configuration could result in it being unagentized.
>>> That's because the agent was failing to find an exact match when it
>>> compared the old and new methods.  It gets to be a rather long story
>>> but the patch prevents, and corrects, this sort of problem.  So, if
>>> the old gnus unagentized some of your servers then the new gnus
>>> could have reversed that error to make then agentized again.
>>
>> I have the agent enabled (gnus-agent is t).  No servers were agentized
>> when I quit Gnus.  My nnimap server was agentized when I started Gnus.
>> I would like to keep gnus-agent t, without automatic agentizing of any
>> of my servers.  I have not edited any server method configurations.
>>
>> I use the latest CVS, updated nightly, and I made sure I was up to
>> date before restarting Gnus.
>
> I've traced this behavior to the gnus-agent-auto-agentize-methods
> variable.  If you don't agentize ANY server, the methods named in this
> variable (currently nntp and nnimap) will be agentized by gnus when
> you start up.  Perhaps we can make this customizable or only apply it
> when the agent is being used for the first time (for example, when
> agent/lib/servers doesn't exist).  I'd rather defer this to the
> original author since I'm not aware of the requirements behind adding it.

The variable was added to behave as you suggest it should.  The code
says (gnus-agentize):

  (unless gnus-agent-covered-methods
    (mapc
     (lambda (server-or-method)
       (let ((method (gnus-server-to-method server-or-method)))
         (when (memq (car method)
                     gnus-agent-auto-agentize-methods)
           (push (gnus-method-to-server method)
                 gnus-agent-covered-methods)
           (setq gnus-agent-method-p-cache nil))))
     (cons gnus-select-method gnus-secondary-select-methods))))

And gnus-agent-covered-methods should be read from
~/News/agent/lib/servers.  So only when g-a-c-m is nil should the auto
agentizing happen.  Hm.  I guess if you deagentize all your servers,
they would be auto-agentized again.  But if no servers are agentized,
what's the point if using the agent?  Perhaps it should disable itself
in that case.

Re: automatic Agentizing of servers (was: Summary buffer

[Ted Zlatanov]

On Tue, 25 Nov 2003, jas@extundo.com wrote:

> The variable was added to behave as you suggest it should.  The code
> says (gnus-agentize):
> 
>   (unless gnus-agent-covered-methods
>     (mapc
>      (lambda (server-or-method)
>        (let ((method (gnus-server-to-method server-or-method)))
>          (when (memq (car method)
>                      gnus-agent-auto-agentize-methods)
>            (push (gnus-method-to-server method)
>                  gnus-agent-covered-methods)
>            (setq gnus-agent-method-p-cache nil))))
>      (cons gnus-select-method gnus-secondary-select-methods))))
> 
> And gnus-agent-covered-methods should be read from
> ~/News/agent/lib/servers.  So only when g-a-c-m is nil should the
> auto agentizing happen.  Hm.  I guess if you deagentize all your
> servers, they would be auto-agentized again.  But if no servers are
> agentized, what's the point if using the agent?  

Because I used to have the agent, then forgot to disable it in my
config file.

> Perhaps it should disable itself in that case.

My suggestion:

I think a warning the first time the user encounters this would be
appropriate, e.g. "do you want to auto-agentize your nnimap
servers?"  That should be the only time the servers file contains nil.

If the user answers yes, agentize away, but make sure that the content
of the servers file reflects the agentization done.  If no, set the
content of the servers file to 'queried for instance.

Thanks!
Ted

Re: automatic Agentizing of servers (was: Summary buffer

[Steinar Bang]

>>>>> Simon Josefsson <jas@extundo.com>:

> And gnus-agent-covered-methods should be read from
> ~/News/agent/lib/servers.  So only when g-a-c-m is nil should the
> auto agentizing happen.  Hm.  I guess if you deagentize all your
> servers, they would be auto-agentized again.  But if no servers are
> agentized, what's the point if using the agent?

I may wish to switch it on again for a server, without having to touch
the configuration file.

> Perhaps it should disable itself in that case.

This was never resolved...?

I did a CVS update yesterday for the first time since October, and
encountered the auto-agentizing behaviour, and didn't like it.

Re: automatic Agentizing of servers (was: Summary buffer

[Simon Josefsson]

Steinar Bang <sb@dod.no> writes:

>>>>>> Simon Josefsson <jas@extundo.com>:
>
>> And gnus-agent-covered-methods should be read from
>> ~/News/agent/lib/servers.  So only when g-a-c-m is nil should the
>> auto agentizing happen.  Hm.  I guess if you deagentize all your
>> servers, they would be auto-agentized again.  But if no servers are
>> agentized, what's the point if using the agent?
>
> I may wish to switch it on again for a server, without having to touch
> the configuration file.

I agree.

>> Perhaps it should disable itself in that case.
>
> This was never resolved...?
>
> I did a CVS update yesterday for the first time since October, and
> encountered the auto-agentizing behaviour, and didn't like it.

I have installed the following.  I did test it slightly, but please
verify if it works.

2003-12-29  Simon Josefsson  <jas@extundo.com>

	* gnus-agent.el (gnus-agentize): Improve auto-agentizing logic.
	Suggested by Steinar Bang <sb@dod.no>.

Index: gnus-agent.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gnus-agent.el,v
retrieving revision 6.183
diff -u -p -u -w -r6.183 gnus-agent.el
--- gnus-agent.el	21 Dec 2003 15:42:11 -0000	6.183
+++ gnus-agent.el	29 Dec 2003 21:36:59 -0000
@@ -608,7 +608,11 @@ minor mode in all Gnus buffers."
               message-send-mail-function)
 	  message-send-mail-real-function 'gnus-agent-send-mail))
 
-  (unless gnus-agent-covered-methods
+  ;; If the servers file doesn't exist, auto-agentize some servers and
+  ;; save the servers file so this auto-agentizing isn't invoked
+  ;; again.
+  (unless (file-exists-p (nnheader-concat gnus-agent-directory "lib/servers"))
+    (gnus-message 3 "First time agent user, agentizing remote groups...")
     (mapc
      (lambda (server-or-method)
        (let ((method (gnus-server-to-method server-or-method)))
@@ -617,7 +621,8 @@ minor mode in all Gnus buffers."
            (push (gnus-method-to-server method)
                  gnus-agent-covered-methods)
            (setq gnus-agent-method-p-cache nil))))
-     (cons gnus-select-method gnus-secondary-select-methods))))
+     (cons gnus-select-method gnus-secondary-select-methods))
+    (gnus-agent-write-servers)))
 
 (defun gnus-agent-queue-setup (&optional group-name)
   "Make sure the queue group exists.

Re: automatic Agentizing of servers (was: Summary buffer

[Steinar Bang]

>>>>> Simon Josefsson <jas@extundo.com>:

> I have installed the following.  I did test it slightly, but please
> verify if it works.

> 2003-12-29  Simon Josefsson  <jas@extundo.com>

> 	* gnus-agent.el (gnus-agentize): Improve auto-agentizing logic.
> 	Suggested by Steinar Bang <sb@dod.no>.

I have patched the .el file, run make in the lisp directory and
started a new xemacs.

If I do J r on the agentized servers in the *Server* buffer, quit
gnus, do
	rm -rf ~/News/agent
and restart gnus, I still find the servers agentized after startup. 

Re: automatic Agentizing of servers (was: Summary buffer

[Steinar Bang]

>>>>> Steinar Bang <sb@dod.no>:

>>>>> Simon Josefsson <jas@extundo.com>:
>> I have installed the following.  I did test it slightly, but please
>> verify if it works.

>> 2003-12-29  Simon Josefsson  <jas@extundo.com>

>> * gnus-agent.el (gnus-agentize): Improve auto-agentizing logic.
>> Suggested by Steinar Bang <sb@dod.no>.

> I have patched the .el file, run make in the lisp directory and
> started a new xemacs.

> If I do J r on the agentized servers in the *Server* buffer, quit
> gnus, do
> 	rm -rf ~/News/agent
> and restart gnus, I still find the servers agentized after startup. 

Hm... I got need-merge on the gnus-agent.el file, and when I did a
merge I got a conflict.  I'll update from CVS and then apply the patch
again.

Re: automatic Agentizing of servers (was: Summary buffer

[Steinar Bang]

>>>>> Steinar Bang <sb@dod.no>:

> Hm... I got need-merge on the gnus-agent.el file, and when I did a
> merge I got a conflict.  I'll update from CVS and then apply the
> patch again.

Looks like it was applied already:
 ~/cvs/gnus.xemacs/lisp$ patch -p0 <agent-patch
 patching file gnus-agent.el
 Reversed (or previously applied) patch detected!  Assume -R? [n]
 Apply anyway? [n]
 Skipping patch.
 2 out of 2 hunks ignored -- saving rejects to file gnus-agent.el.rej

I'll recompile and restart and see what the behaviour's like.

Re: automatic Agentizing of servers (was: Summary buffer

[Steinar Bang]

>>>>> Steinar Bang <sb@dod.no>:

> I'll recompile and restart and see what the behaviour's like.

Now I've recompiled and started a fresh XEmacs, and the servers are
still agentized when I start up (if I do an ls -al on ~/News/agent/ I
can see stuff appearing there during startup).

Here's a few messages from the minibuffer during Gnus startup.

...
Reading /home/sb/.newsrc.eld...
Loading efs-cu...done
Loading efs-cu...
Loading bbdb-gnus...done
Loading bbdb-gnus...
First time agent user, agentizing remote groups...
Loading gnus-agent...done
Loading gnus-agent...
Loading gnus-demon...done
Loading gnus-demon...
Loading executable...done
Loading executable...
Loading gnus-start...done
Loading gnus-start...
Loading gnus...done
Loading gnus-xmas...done
Loading gnus-xmas...
Loading gnus...
...

My platform:
 - Gnus CVS update as of a few minutes ago
 - XEmacs 21.4 (patch 6) "Common Lisp" [Lucid] (i386-debian-linux, Mule) of Sat Apr  6 2002 on eeyore
 - Intel PII, running debian sarge testing/unstable

Re: automatic Agentizing of servers (was: Summary buffer

[Simon Josefsson]

Steinar Bang <sb@dod.no> writes:

>>>>>> Simon Josefsson <jas@extundo.com>:
>
>> I have installed the following.  I did test it slightly, but please
>> verify if it works.
>
>> 2003-12-29  Simon Josefsson  <jas@extundo.com>
>
>> 	* gnus-agent.el (gnus-agentize): Improve auto-agentizing logic.
>> 	Suggested by Steinar Bang <sb@dod.no>.
>
> I have patched the .el file, run make in the lisp directory and
> started a new xemacs.
>
> If I do J r on the agentized servers in the *Server* buffer, quit
> gnus, do
> 	rm -rf ~/News/agent
> and restart gnus, I still find the servers agentized after startup. 

Uhm, but what would you expect to happen?  The knowledge about which
servers are agentized and which are not is stored in
~/News/agent/lib/servers, so if you remove that file, Gnus will
auto-agentize your servers.

The point of the patch is that auto-agentification only happens once
(unless you modify ~/News/agent/ manually).  I think if a user remove
~/News/agent she wishes to start afresh, and auto-agentification is
useful in that case.

What do you think?  Can you suggest/describe a better logic that does
what you want?

Re: automatic Agentizing of servers (was: Summary buffer

[Steinar Bang]

>>>>> Simon Josefsson <jas@extundo.com>:

> Uhm, but what would you expect to happen?  The knowledge about which
> servers are agentized and which are not is stored in
> ~/News/agent/lib/servers, so if you remove that file, Gnus will
> auto-agentize your servers.

Ah, OK.  Right now it only contains the text nil, and no servers were
agentized when I started Gnus.

Can I delete everything in the ~/News/agent/ directory, except this
file? 

> The point of the patch is that auto-agentification only happens once
> (unless you modify ~/News/agent/ manually).  I think if a user
> remove ~/News/agent she wishes to start afresh, and
> auto-agentification is useful in that case.

> What do you think?  Can you suggest/describe a better logic that
> does what you want?

Well, for me auto-agentizing is unexpected behaviour, and I wouldn't
wish it ever to occur.

I want to agentize servers when I say J a in the *Server* buffer,
and only then.

Re: automatic Agentizing of servers (was: Summary buffer

[Simon Josefsson]

Steinar Bang <sb@dod.no> writes:

>>>>>> Simon Josefsson <jas@extundo.com>:
>
>> Uhm, but what would you expect to happen?  The knowledge about which
>> servers are agentized and which are not is stored in
>> ~/News/agent/lib/servers, so if you remove that file, Gnus will
>> auto-agentize your servers.
>
> Ah, OK.  Right now it only contains the text nil, and no servers were
> agentized when I started Gnus.
>
> Can I delete everything in the ~/News/agent/ directory, except this
> file? 

Yes.  You can delete that file too, of course, but then some servers
will be auto-agentized when you restart.

>> The point of the patch is that auto-agentification only happens once
>> (unless you modify ~/News/agent/ manually).  I think if a user
>> remove ~/News/agent she wishes to start afresh, and
>> auto-agentification is useful in that case.
>
>> What do you think?  Can you suggest/describe a better logic that
>> does what you want?
>
> Well, for me auto-agentizing is unexpected behaviour, and I wouldn't
> wish it ever to occur.
>
> I want to agentize servers when I say J a in the *Server* buffer,
> and only then.

Then don't delete ~/News/agent/lib/servers and remove the
auto-agentized servers. :-)

I guess this could be customizable.  Cvs update again and customize
`gnus-agent-auto-agentize-methods' to an empty list.  Then you can
wipe out ~/News/agent/ and nothing will be auto-agentized.  I have
added this to the manual:

`gnus-agent-auto-agentize-methods'
     If you have never used the Agent before (or more technically, if
     `~/News/agent/lib/servers' does not exist), Gnus will
     automatically agentize a few servers for you.  This variable
     control which backends should be auto-agentized.  It is typically
     only useful to agentize remote backends.  The auto-agentizing has
     the same effect as running `J a' on the servers (see *note Server
     Agent Commands::).  If the file exist, you must manage the servers
     manually by adding or removing them, this variable is only
     applicable the first time you start Gnus.  The default is `(nntp
     nnimap)'.

Re: automatic Agentizing of servers (was: Summary buffer

[Kevin Greiner]

Simon Josefsson <jas@extundo.com> writes:

> Steinar Bang <sb@dod.no> writes:
>
>>>>>>> Simon Josefsson <jas@extundo.com>:
>>
>>> Uhm, but what would you expect to happen?  The knowledge about which
>>> servers are agentized and which are not is stored in
>>> ~/News/agent/lib/servers, so if you remove that file, Gnus will
>>> auto-agentize your servers.
>>
>> Ah, OK.  Right now it only contains the text nil, and no servers were
>> agentized when I started Gnus.
>>
>> Can I delete everything in the ~/News/agent/ directory, except this
>> file? 
>
> Yes.  You can delete that file too, of course, but then some servers
> will be auto-agentized when you restart.
>
>>> The point of the patch is that auto-agentification only happens once
>>> (unless you modify ~/News/agent/ manually).  I think if a user
>>> remove ~/News/agent she wishes to start afresh, and
>>> auto-agentification is useful in that case.
>>
>>> What do you think?  Can you suggest/describe a better logic that
>>> does what you want?
>>
>> Well, for me auto-agentizing is unexpected behaviour, and I wouldn't
>> wish it ever to occur.

That's probably because the agent was originally intended for offline
use.  Auto-agentizing was added to support client-side caching of
articles (an online performance option).  Personally, I also find it a
little strange but it is a better solution than having the agent, the
cache, AND a client-side cache storing articles on your local hard
drive.

>> I want to agentize servers when I say J a in the *Server* buffer,
>> and only then.
>
> Then don't delete ~/News/agent/lib/servers and remove the
> auto-agentized servers. :-)
>
> I guess this could be customizable.  Cvs update again and customize
> `gnus-agent-auto-agentize-methods' to an empty list.  Then you can
> wipe out ~/News/agent/ and nothing will be auto-agentized.  I have
> added this to the manual:
>
> `gnus-agent-auto-agentize-methods'
>      If you have never used the Agent before (or more technically, if
>      `~/News/agent/lib/servers' does not exist), Gnus will
>      automatically agentize a few servers for you.  This variable
>      control which backends should be auto-agentized.  It is typically
>      only useful to agentize remote backends.  The auto-agentizing has
>      the same effect as running `J a' on the servers (see *note Server
>      Agent Commands::).  If the file exist, you must manage the servers
>      manually by adding or removing them, this variable is only
>      applicable the first time you start Gnus.  The default is `(nntp
>      nnimap)'.

That's inappropriate as gnus-agent-auto-agentize-methods isn't
customizable.  It is also incorrect as, as I mentioned earlier, the
agent has more uses than agentizing remote backends.

Kevin

Re: automatic Agentizing of servers (was: Summary buffer

[Simon Josefsson]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

>> `gnus-agent-auto-agentize-methods'
>>      If you have never used the Agent before (or more technically, if
>>      `~/News/agent/lib/servers' does not exist), Gnus will
>>      automatically agentize a few servers for you.  This variable
>>      control which backends should be auto-agentized.  It is typically
>>      only useful to agentize remote backends.  The auto-agentizing has
>>      the same effect as running `J a' on the servers (see *note Server
>>      Agent Commands::).  If the file exist, you must manage the servers
>>      manually by adding or removing them, this variable is only
>>      applicable the first time you start Gnus.  The default is `(nntp
>>      nnimap)'.
>
> That's inappropriate as gnus-agent-auto-agentize-methods isn't
> customizable.

Try 'cvs up'.

> It is also incorrect as, as I mentioned earlier, the agent has more
> uses than agentizing remote backends.

When do you want to agentize a non-remote backend like nnml or
nnfolder?  In any case, it does say 'typically', so weird situations
like nnml over slow remote NFS is conceivable.  Can you suggest (or
better, commit) improved wording?

Re: automatic Agentizing of servers (was: Summary buffer

[Kevin Greiner]

Simon Josefsson <jas@extundo.com> writes:

> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>
>>> `gnus-agent-auto-agentize-methods'
>>>      If you have never used the Agent before (or more technically, if
>>>      `~/News/agent/lib/servers' does not exist), Gnus will
>>>      automatically agentize a few servers for you.  This variable
>>>      control which backends should be auto-agentized.  It is typically
>>>      only useful to agentize remote backends.  The auto-agentizing has
>>>      the same effect as running `J a' on the servers (see *note Server
>>>      Agent Commands::).  If the file exist, you must manage the servers
>>>      manually by adding or removing them, this variable is only
>>>      applicable the first time you start Gnus.  The default is `(nntp
>>>      nnimap)'.
>>
>> That's inappropriate as gnus-agent-auto-agentize-methods isn't
>> customizable.
>
> Try 'cvs up'.
>
>> It is also incorrect as, as I mentioned earlier, the agent has more
>> uses than agentizing remote backends.
>
> When do you want to agentize a non-remote backend like nnml or
> nnfolder?  In any case, it does say 'typically', so weird situations
> like nnml over slow remote NFS is conceivable.  Can you suggest (or
> better, commit) improved wording?

My apologies for mispeaking.  I don't like stepping on capabilities
that other people introduced and, as this thread progressed, that is
what seemed to be happening here.  I just checked backwards in the log
only to find that you introduced the gnus-agent-auto-agentize-methods
variable.  That makes you the expert on how it should be used, or in
this case initialized.

Kevin

Re: automatic Agentizing of servers (was: Summary buffer

[Simon Josefsson]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

>>> It is also incorrect as, as I mentioned earlier, the agent has more
>>> uses than agentizing remote backends.
>>
>> When do you want to agentize a non-remote backend like nnml or
>> nnfolder?  In any case, it does say 'typically', so weird situations
>> like nnml over slow remote NFS is conceivable.  Can you suggest (or
>> better, commit) improved wording?
>
> My apologies for mispeaking.  I don't like stepping on capabilities
> that other people introduced and, as this thread progressed, that is
> what seemed to be happening here.  I just checked backwards in the log
> only to find that you introduced the gnus-agent-auto-agentize-methods
> variable.  That makes you the expert on how it should be used, or in
> this case initialized.

But it doesn't rule out the possibility that I'm wrong. :-)

The auto-agentification is rather simplistic, basically I believe it
now just work like:

IF NOT EXISTS ~/News/agent/lib/servers THEN
  DOLIST (cons gnus-select-method gnus-secondary-select-methods)
    method = (gnus-method-to-server LISTEL)
    IF CAR(method) MEMBER OF gnus-agent-auto-agentize-methods
       ADD method TO gnus-agent-covered-methods
  WRITE gnus-agent-covered-methods INTO ~/News/agent/lib/servers

With apologies for the... interesting looking... pseduo-code.

Re: automatic Agentizing of servers (was: Summary buffer

[Harry Putnam]

Simon Josefsson <jas@extundo.com> writes:

> But it doesn't rule out the possibility that I'm wrong. :-)
>
> The auto-agentification is rather simplistic, basically I believe it
> now just work like:
>
> IF NOT EXISTS ~/News/agent/lib/servers THEN
>   DOLIST (cons gnus-select-method gnus-secondary-select-methods)
>     method = (gnus-method-to-server LISTEL)
>     IF CAR(method) MEMBER OF gnus-agent-auto-agentize-methods
>        ADD method TO gnus-agent-covered-methods
>   WRITE gnus-agent-covered-methods INTO ~/News/agent/lib/servers

Maybe its been explained before but I'm having trouble understanding
why we need any auto agentization.  Seems like it should always
require a `J a' on the server.  What is really saved or made better
by having it automatic?

Re: automatic Agentizing of servers (was: Summary buffer

[Steinar Bang]

>>>>> Harry Putnam <reader@newsguy.com>:

> Maybe its been explained before but I'm having trouble understanding
> why we need any auto agentization.  Seems like it should always
> require a `J a' on the server.  What is really saved or made better
> by having it automatic?

That describes my position as well.

Ie. I can live with today's behaviour as long as I don't have to
remove agentizing every time I start Gnus, but I don't get why it has
to be this way.

Re: automatic Agentizing of servers (was: Summary buffer

[Simon Josefsson]

Harry Putnam <reader@newsguy.com> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> But it doesn't rule out the possibility that I'm wrong. :-)
>>
>> The auto-agentification is rather simplistic, basically I believe it
>> now just work like:
>>
>> IF NOT EXISTS ~/News/agent/lib/servers THEN
>>   DOLIST (cons gnus-select-method gnus-secondary-select-methods)
>>     method = (gnus-method-to-server LISTEL)
>>     IF CAR(method) MEMBER OF gnus-agent-auto-agentize-methods
>>        ADD method TO gnus-agent-covered-methods
>>   WRITE gnus-agent-covered-methods INTO ~/News/agent/lib/servers
>
> Maybe its been explained before but I'm having trouble understanding
> why we need any auto agentization.  Seems like it should always
> require a `J a' on the server.  What is really saved or made better
> by having it automatic?

The auto-agentification make the use-agent-as-cache the default
behaviour, for remote backends.  Most MUAs these days cache the
equivalent of NOV information in groups, and I think it is useful.  If
nntp/nnimap groups were not auto-agentified, or if the user removed
those servers from the agent, entering groups with thousands of
articles would download the NOV data every time you enter the group,
this can be slow.  With the agent NOV cache, entering even groups with
20000 articles is rather fast, because almost nothing have to be
transfered over the network.

So essentially the reason for auto-agentifying some servers is that it
improves performance, and doesn't (shouldn't) affect anything else.

Steinar Bang <sb@dod.no> writes:

> Ie. I can live with today's behaviour as long as I don't have to
> remove agentizing every time I start Gnus, but I don't get why it has
> to be this way.

Hm, maybe if we look at it from the reverse point of view: why don't
you want the nntp/nnimap backends in the agent?  Does it cause any
problems?  Don't you find entering large nnimap/nntp groups slow?
I.e., waiting for all NOV data to be downloaded?  If the servers are
agentified, only the first time you enter a group will be slow.

(Btw, nnimap has its own NOV cache, but it is disabled when the agent
is enabled.  Perhaps it should only be disabled if the current server
is not in the agent, instead.  But even so, having two NOV caches
within Gnus just make it more difficult to maintain; it is easier to
fix bugs in one NOV cache than to fix them in two.  So it would be
better if the agent NOV cache was used all the time, which is what
auto-agentification achieves.  You can enable the nnimap-specific NOV
cache by toggling `nnimap-nov-is-evil'.)

Re: automatic Agentizing of servers (was: Summary buffer

[Steinar Bang]

>>>>> Simon Josefsson <jas@extundo.com>:

> Hm, maybe if we look at it from the reverse point of view: why don't
> you want the nntp/nnimap backends in the agent?

The nnimap server that was auto-agentized resides on the same machine
as the Gnus in XEmacs process (ie. the machine I'm typing this on),
and I don't have disk space to cache the NNTP server (though a new
disk is in the mail).

I've also had problems seeing all articles in nnimap earlier, when I
was running against the same nnimap server from a remote site, and
using the agent for speedup.  But from a different thread I read
yesterday, it looked like perhaps you have fixed this problem?

Re: automatic Agentizing of servers (was: Summary buffer

[Simon Josefsson]

Steinar Bang <sb@dod.no> writes:

>>>>>> Simon Josefsson <jas@extundo.com>:
>
>> Hm, maybe if we look at it from the reverse point of view: why don't
>> you want the nntp/nnimap backends in the agent?
>
> The nnimap server that was auto-agentized resides on the same machine
> as the Gnus in XEmacs process (ie. the machine I'm typing this on),
> and I don't have disk space to cache the NNTP server (though a new
> disk is in the mail).

Ah!  I understand, thanks for explaining.

Do you think the default of enabling the agent as cache should be
changed though?  I suspect most users of nntp/nnimap access remote
servers, most of which are slower than local disk, and have disk space
to waste for caching header data, but I may be wrong.

Disabling the behaviour is (now) only J r in the server buffer too, or
customizing gnus-agent-auto-agentize-methods if ~/News/agents is
removed periodically, which doesn't sound too burdensome to me.

> I've also had problems seeing all articles in nnimap earlier, when I
> was running against the same nnimap server from a remote site, and
> using the agent for speedup.  But from a different thread I read
> yesterday, it looked like perhaps you have fixed this problem?

Perhaps that was Kevin, I don't recall seeing or fixing anything
similar.

Re: automatic Agentizing of servers (was: Summary buffer

[Harry Putnam]

Simon Josefsson <jas@extundo.com> writes:

> Ah!  I understand, thanks for explaining.
>
> Do you think the default of enabling the agent as cache should be
> changed though?  I suspect most users of nntp/nnimap access remote
> servers, most of which are slower than local disk, and have disk space
> to waste for caching header data, but I may be wrong.

I realize you addressed this to Steiner... but I also raised a
question about needing auto-agentizing.  After reading your
explanation as to why it is a good thing.  I am now convinced it is
in fact the best thing.

Re: automatic Agentizing of servers (was: Summary buffer

[Steinar Bang]

>>>>> Simon Josefsson <jas@extundo.com>:

> Do you think the default of enabling the agent as cache should be
> changed though? 

I don't know.  If your changes had been in when I upgraded, I would
have done J r on both agentized servers and not given it a second
thought.

> I suspect most users of nntp/nnimap access remote servers, most of
> which are slower than local disk, and have disk space to waste for
> caching header data, but I may be wrong.

Yes.  I suspect 233MHz PIIs with 4GB disks, serving as IMAP servers,
and web servers, as well as someone's desktop machine, are the
exception, rather than the rule...:-)

>> I've also had problems seeing all articles in nnimap earlier, when
>> I was running against the same nnimap server from a remote site,
>> and using the agent for speedup.  But from a different thread I
>> read yesterday, it looked like perhaps you have fixed this problem?

> Perhaps that was Kevin, I don't recall seeing or fixing anything
> similar.

I thought it was you, but I was unable to locate the thread, and/or
the message.  Perhaps I was hallucinating?

Re: automatic Agentizing of servers (was: Summary buffer

[Steinar Bang]

>>>>> Simon Josefsson <jas@extundo.com>:

> Then don't delete ~/News/agent/lib/servers and remove the
> auto-agentized servers. :-)

I can live with that.  I was just trying to explain what I thought is
expected default behaviour.