Gnus v5.2.8 is released

Gnus v5.2.8 is released

[Lars Magne Ingebrigtsen]

Bug fixes.

Get it from <URL:http://www.ifi.uio.no/~larsi/gnus.tar.gz> or 
"ftp.ifi.uio.no:/pub/emacs/gnus/".

ChangeLog since last release:

Wed Jun  5 17:17:00 1996  Lars Magne Ingebrigtsen  <larsi@trym.ifi.uio.no>

	* nndoc.el (nndoc-type-alist): New babyl head begin.
	(nndoc-babyl-head-begin): New function.

Wed Jun  5 16:26:55 1996  Lars Magne Ingebrigtsen  <larsi@hler.ifi.uio.no>

	* gnus.el (gnus-summary-save-article): Remove headers.

Wed Jun  5 18:16:55 1996  Lars Magne Ingebrigtsen  <larsi@ylfing.ifi.uio.no>

	* gnus.el (gnus-read-old-newsrc-el-file): Would bug out.

Wed Jun  5 12:43:22 1996  Lars Magne Ingebrigtsen  <larsi@hler.ifi.uio.no>

	* gnus-score.el: `V f' to flush the cache.
	(gnus-score-flush-cache): Save scores before flushing.

	* gnus-cite.el (gnus-cite-prefix-regexp): Removed "-" as cite
	prefix. 

	* gnus.el (gnus-summary-caesar-message): Use message.

	* gnus-cite.el (gnus-cite-prefix-regexp): Allow "-" as a cite
	prefix. 

	* nnvirtual.el (nnvirtual-convert-headers): Wouldn't convert.

	* gnus-cus.el (()): Have `gnus-mouse-face' respect gnus-visual.

Wed Jun  5 12:52:15 1996  Lars Magne Ingebrigtsen  <lars@eyesore.no>

	* dgnushack.el (custom-file): Changed setq.

Tue Jun  4 13:46:45 1996  Scott Byer  <byer@mv.us.adobe.com>

	* nnfolder.el (nnfolder-read-folder) Take an additional parameter,
 	scanning, which is t when we are only scanning for new news.  In
 	this case, if the modtime of the file hasn't changed since we last
 	scanned it, we don't bother reading the file in, and simply return
 	nil.  When we do scan it, pay attention to the
 	nnfolder-distrust-mbox variable, and only scan forward from the
 	last marked message when nil.  After scanning, remember the
 	modtime of the visited buffer.

	* nnfolder.el (nnfolder-save-mail) If nnfolder-current-buffer is
 	nil, make sure any open group is closed before changing the group
 	- in the case where a group was opened for scanning but not read
 	in because it wasn't touched, this forces the read.

	* nnfolder.el (nnfolder-possibly-change-group) Take an additional
 	optional variable, which indicated if we're scanning.  Passes it
 	on to nnfolder-read-folder, and is prepared for
 	nnfolder-read-folder to return nil for nnfolder-current-buffer.
  	If we get a request to change to the currently open group, and
 	nnfolder-current-buffer is nil (we're on the tail end of a scan),
 	simply return.

	* nnfolder.el (nnfolder-request-scan) Inform
 	nnfolder-possibly-change-group that we're scanning.

	* nnfolder.el (nnfolder-scantime-alist) New internal variable.
  	Keep track of the last scantime of each mbox.

	* nnfolder.el (nnfolder-distrust-mbox) New variable.  When t,
 	nnfolder-read-folder reverts to it's old behavior of scanning an
 	entire file looking for unmarked messages.  When nil (the
 	default), scans forward from the last marked message.  Unless you
 	have an external mailer which inserts new messages in the middle
 	of your mailboxes, leave nil.

Wed Jun  5 09:20:38 1996  Lars Magne Ingebrigtsen  <lars@eyesore.no>

	* message.el (message-goto-body): Expand abbrev.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Gnus v5.2.8 is released

[Sudish Joseph]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> Tue Jun  4 13:46:45 1996  Scott Byer  <byer@mv.us.adobe.com>
[ Lots of cool speedups for nnfolder. ]

On the subject of mail speedups, it'd be nice if nnmail-get-new-mail
didn't loop over all the specified spools for every single group.
This doesn't seem like a speed hit when all you're paying is a stat on
an guaranteed-to-be-empty spool file for all groups after the
first...but it's -huge- when one of those spools is a pop server
accessed over a PPP link.  I'd even consider this a bug. :-)

I thought it'd be a simple tweak to nnmail-get-spool-files, and I
still do.  But I'm not too clear on the interaction with summary-local
settings of nnmail-spool-file (i.e., from the group params).  I also
spent all my time wandering around with my jaw open inside the
aladdin's cave of nnoo.el (very very kewl, Lars).  Should have known
better than to breeze into Lars's code after 5-6 months expecting
things to stay the same.

If someone would clarify/enumerate the ways in which spool files can
be specified and/or modified on a per-group basis, I'll fix this over
the weekend (gonna read CoS till then :-).

[ Unrelated, but I'll throw it in here ]
Maybe we should stare long and hard at the different sources of
messages, and how they differ.  Right now, it's still somewhat random
as to how different backends access new messages--I mean how the user
specifies the source of new messages, nnoo unifies the actual code
nicely.

For instance, most mail backends will get mail from the central
spool.  The central spool is split into every group and should
be accessed just once per get-new-news cycle.  Some groups will have
their own spools (nnmail-use-procmail).

POP is akin to a central spool.

News, OTOH, always has a unique source per group.  

IMAP will use *both* methods.

It'd be nice if there was a way of specifying the characteristics of a
backend, so that nnmail-get-new-mail could be intelligent about how
often and when to access the spools for a given backend, w/o having
that information hardcoded.

It'd also make it easier to make GNUS extensible in the sense of being
able to 
  1) add nnfoo.elc to your load-path 
  2) set a few variables that completely specify it's behaviour 
  3) call a GNUS-provided function to register itself with GNUS.
and have it work just as well as any native backend.

nnoo goes a long way towards this already.

-- 
Sudish 

Re: Gnus v5.2.8 is released

[Lars Magne Ingebrigtsen]

Sudish Joseph <sudish@ix.netcom.com> writes:

> On the subject of mail speedups, it'd be nice if nnmail-get-new-mail
> didn't loop over all the specified spools for every single group.
> This doesn't seem like a speed hit when all you're paying is a stat on
> an guaranteed-to-be-empty spool file for all groups after the
> first...but it's -huge- when one of those spools is a pop server
> accessed over a PPP link.  I'd even consider this a bug. :-)

nnmail tries to avoid querying POP servers by maintaining a
`nnmail-moved-inboxes' list that it checks.  Perhaps this doesn't work
as it's supposed to?  I'm not sure -- I don't have access to a POP
server.  Could somebody have a closer look at `nnmail-move-inbox' in
"nnmail.el" and see whether things work or not?

(The `nnmail-moved-inboxes' variable is cleared in `post-command-hook'
in the group buffer, so `g' `g' will read the spools twice.)

> It'd also make it easier to make GNUS extensible in the sense of being
> able to 
>   1) add nnfoo.elc to your load-path 
>   2) set a few variables that completely specify it's behaviour 
>   3) call a GNUS-provided function to register itself with GNUS.
> and have it work just as well as any native backend.

I've added this last item to the Red Gnus todo list.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Gnus v5.2.8 is released

[Colin Rafferty]

Sudish Joseph <sudish@ix.netcom.com> writes:

> On the subject of mail speedups, it'd be nice if nnmail-get-new-mail
> didn't loop over all the specified spools for every single group.

I have the following function bound to M-C-g in *Group*.  It grabs and
splits my mail into my nnml folders, and then only updates the folders
that have changed.

Now that I think about it, it probably doesn't update virtual folders at
all.  I don't have any, so I don't care.

(defun gnus-group-get-new-nnml ()
  "Get new nnml mail only."
  (interactive)
  (let ((gnus-group-new-mail-list nil)
	(nnml-prepare-save-mail-hook
	 (cons '(lambda ()
		  (setq gnus-group-new-mail-list
			(union gnus-group-new-mail-list
			       (mapcar 'car group-art))))
	       nnml-prepare-save-mail-hook)))
    (nnml-request-scan)
    (let ((gnus-group-marked (mapcar '(lambda (group)
					(concat "nnml:" group))
				     gnus-group-new-mail-list)))
      (gnus-group-get-new-news-this-group))
    (when gnus-goto-next-group-when-activating
      (gnus-group-next-unread-group 1 t))
    (gnus-summary-position-point)
    (gnus-group-list-groups)
    gnus-group-new-mail-list))

-- 
Colin