Red Gnus v0.1 is released

Red Gnus v0.1 is released

[Lars Magne Ingebrigtsen]

... and we're off.

Expect major bugs in this release.  Not for the faint of heart.

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

ChangeLog since last release:

Tue Jul 30 23:02:51 1996  Lars Magne Ingebrigtsen  <larsi@ifi.uio.no>

	* gnus.el: Red Gnus v0.1 is released.

Tue Jul 30 22:34:11 1996  Lars Magne Ingebrigtsen  <larsi@ifi.uio.no>

	* nntp.el (nntp-find-connection-buffer): New function.
	(nntp-retrieve-headers): Use it.

Tue Jul 30 00:00:28 1996  Lars Magne Ingebrigtsen  <lars@eyesore.no>

	* nndoc.el (nndoc-add-type): New function.
	(nndoc-guess-type): New function.
	(nndoc-set-delims): New definition.

	* nntp.el (nntp-open-server): Init server buffer.

	* gnus.el (gnus-group-prefixed-name): Do the right thing with nil
	methods. 
	(gnus-group-rename-group): Would act oddly when renaming native
	groups. 

Mon Jul 29 14:17:30 1996  Lars Magne Ingebrigtsen  <lars@eyesore.no>

	* gnus-load.el (gnus-startup-hook): Removed hilit removal.

	* gnus-async.el: New file.

	* gnus-int.el (gnus-asynchronous-p): New function.

	* nntp.el: Replaced with new, asynchronous version.

Mon Jul 29 11:48:07 1996  Paul Franklin  <paul@transmeta.com>

	* gnus-sum.el (gnus-pdf-simplify-subject): New function.
	(gnus-summary-simplify-subject-query): New command.

Mon Jul 29 10:05:30 1996  Lars Magne Ingebrigtsen  <lars@eyesore.no>

	* gnus-sum.el (gnus-summary-mode-map): Command for emphasis.

	* gnus-art.el (gnus-article-wash-status): Report emphasis.

	* article.el (article-unhide-text-type): New function.
	(article-emphasize): New function.
	(article-emphasis-alist): New variable.

	* gnus-score.el (gnus-score-headers): Hook into advanced scoring.

	* gnus-logic.el: New file.

	* article.el (article-treat-overstrike): Mark hiding type.

Mon Jul 29 10:00:52 1996  d. hall  <dhall@illusion.apk.net>

	* gnus-art.el (gnus-article-wash-status): New function.

Sun Jul 28 15:20:19 1996  Lars Magne Ingebrigtsen  <lars@eyesore.no>

	* article.el (article-hidden-arg): Renamed all variables and
	functions to `article-'.

	* gnus.el: Split file into gnus-start.el, gnus-group.el,
	gnus-sum.el, gnus-art.el, gnus-win.el, gnus-load.el, gnus-util.el,
	gnus-bcklg.el, gnus-spec.el, article.el, and gnus-int.el.


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

Re: Red Gnus v0.1 is released

[Steven L Baur]

> Expect major bugs in this release.  Not for the faint of heart.

Attempting to byte compile this on XEmacs produced a whole bunch of
errors:
(For every place gnus-load or gnus is required)
Loading gnus-load...
While compiling toplevel forms in file /usr/lib/xemacs/rgnus-0.01/lisp/earcon.el:
  !! Symbol's value as variable is void ((gnus-default-nntp-server))



Compiling /usr/lib/xemacs/rgnus-0.01/lisp/nndoc.el...
While compiling nndoc-set-delims in file /usr/lib/xemacs/rgnus-0.01/lisp/nndoc.el:
  ** assignment to free variable guess
While compiling nndoc-add-type:
  ** memq called with 1 arg, but requires 2
Wrote /usr/lib/xemacs/rgnus-0.01/lisp/nndoc.elc


Upon retrying with `make some' I got some error messages I didn't know
existed:
Compiling /usr/lib/xemacs/rgnus-0.01/lisp/earcon.el...
While compiling toplevel forms in file /usr/lib/xemacs/rgnus-0.01/lisp/earcon.el:
  !! error (("optimizer error: missed tags ((25096 TAG 9))"))

While compiling toplevel forms in file /usr/lib/xemacs/rgnus-0.01/lisp/gnus-group.el:
  !! error (("optimizer error: missed tags ((25096 TAG 9))"))

While compiling toplevel forms in file /usr/lib/xemacs/rgnus-0.01/lisp/gnus-kill.el:
  !! error (("optimizer error: missed tags ((16392 TAG 9) (2241 TAG 8))"))

While compiling toplevel forms in file /usr/lib/xemacs/rgnus-0.01/lisp/gnus-msg.el:
  !! error (("optimizer error: missed tags ((16392 TAG 3) (2241 TAG 2))"))

While compiling toplevel forms in file /usr/lib/xemacs/rgnus-0.01/lisp/gnus-picon.el:
  !! File error (("Cannot open load file" "xpm"))

While compiling toplevel forms in file /usr/lib/xemacs/rgnus-0.01/lisp/gnus-score.el:
  !! error (("optimizer error: missed tags ((16392 TAG 6) (2241 TAG 5))"))


While compiling toplevel forms in file /usr/lib/xemacs/rgnus-0.01/lisp/gnus-sum.el:
  !! error (("optimizer error: missed tags ((49672 TAG 9))"))

While compiling toplevel forms in file /usr/lib/xemacs/rgnus-0.01/lisp/gnus-topic.el:
  !! error (("optimizer error: missed tags ((25096 TAG 2))"))

While compiling toplevel forms in file /usr/lib/xemacs/rgnus-0.01/lisp/gnus-vis.el:
  !! error (("optimizer error: missed tags ((25096 TAG 9))"))

While compiling toplevel forms in file /usr/lib/xemacs/rgnus-0.01/lisp/gnus-win.el:
  !! error (("optimizer error: missed tags ((16392 TAG 9) (2241 TAG 8))"))

While compiling toplevel forms in file /usr/lib/xemacs/rgnus-0.01/lisp/gnus-xmas.el:
  !! File error (("Cannot open load file" "text-props"))

> ... and we're off.

Whee!
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

Re: Red Gnus v0.1 is released

[Sudish Joseph]

In article <w8sk9vl8nes.fsf@hler.ifi.uio.no>,
Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> .... and we're off.

Yay!  

I had to move some stuff around in gnus-load.el to get it to compile
on XEmacs.  Silly patch enclosed.

gnus-startup-hook runs somewhat earlier than before, in the sense that
various keymaps aren't defined at the time it's run.  This causes
bbdb-insinuate-gnus to bomb out.  My hack was to require gnus-sum in
gnus-start.el.  This is unsatisfactory, however, coz I like the fact
that stuff isn't loaded until needed (not that GNUS is very useful w/o
a summary buffer, but I prefer the load time cost spread over various
user drivern activities).

How about defvaring all keymaps to empty keymaps in gnus-start or
someplace equally early and having the actual keymap setup code
checking to see if an entry already exists bwefore adding one?  

Quick note on what I assume in the new async nntp (I'll look at it
after my netrek INL game :-): it seems to be doing readahead on
articles in the next visited group...very cool, if so.  

But, this can cause problems if you do something that requires
bandwidth in itself (for instance, hitting "g" locks me up solid coz
my PPP link is being used for the async fetch -- the b/w won't even be
shared well coz the SYN's will take a longish time to get through to
establish the new connection).  Maybe some kind of scheduler or
limiter for the async stuff?  Hmm, maybe just using one connection for
all NNTP I/O would suffice since this would serialize requests
automatically, all that'd be needed is intelligent prioritized
scheduling (with preemption based on priority) of commands over that
one link.  

(I'm not complaining at all, I -love- having my PPP line used -all-
the time.)

Back to the red beast,
-Sudish

diff -c /home/sj/xemacs/site-lisp/ding/lisp/gnus-load.el~ /home/sj/xemacs/site-lisp/ding/lisp/gnus-load.el
*** /home/sj/xemacs/site-lisp/ding/lisp/gnus-load.el~	Tue Jul 30 20:25:25 1996
--- /home/sj/xemacs/site-lisp/ding/lisp/gnus-load.el	Tue Jul 30 20:25:25 1996
***************
*** 101,106 ****
--- 101,116 ----
  There is a lot more to know about select methods and virtual servers -
  see the manual for details.")
  
+ (defvar gnus-secondary-select-methods nil
+   "*A list of secondary methods that will be used for reading news.
+ This is a list where each element is a complete select method (see
+ `gnus-select-method').
+ 
+ If, for instance, you want to read your mail with the nnml backend,
+ you could set this variable:
+ 
+ (setq gnus-secondary-select-methods '((nnml \"\")))")
+ 
  (defvar gnus-message-archive-method 
    `(nnfolder
      "archive"
***************
*** 136,151 ****
  However, you may wish to store the message on some other server.  In
  that case, just return a fully prefixed name of the group --
  \"nnml+private:mail.misc\", for instance.")
- 
- (defvar gnus-secondary-select-methods nil
-   "*A list of secondary methods that will be used for reading news.
- This is a list where each element is a complete select method (see
- `gnus-select-method').
- 
- If, for instance, you want to read your mail with the nnml backend,
- you could set this variable:
- 
- (setq gnus-secondary-select-methods '((nnml \"\")))")
  
  (defvar gnus-backup-default-subscribed-newsgroups
    '("news.announce.newusers" "news.groups.questions" "gnu.emacs.gnus")
--- 146,151 ----

Re: Red Gnus v0.1 is released

[Steven L Baur]

Sudish's patch didn't help me at all :-(.

gnus-default-nntp-server is defined too late in gnus-load.el, so I
tried this patch:
===================================================================
RCS file: RCS/gnus-load.el,v
retrieving revision 1.1
diff -u -r1.1 gnus-load.el
--- gnus-load.el	1996/07/30 23:53:48	1.1
+++ gnus-load.el	1996/07/31 01:11:35
@@ -34,6 +34,13 @@
 ;; Site dependent variables.  These variables should be defined in
 ;; paths.el.
 
+(defvar gnus-default-nntp-server nil
+  "Specify a default NNTP server.
+This variable should be defined in paths.el, and should never be set
+by the user.
+If you want to change servers, you should use `gnus-select-method'.
+See the documentation to that variable.")
+
 ;; Don't touch this variable.
 (defvar gnus-nntp-service "nntp"
   "*NNTP service name (\"nntp\" or 119).
@@ -139,13 +146,6 @@
 you could set this variable:
 
 (setq gnus-secondary-select-methods '((nnml \"\")))")
-
-(defvar gnus-default-nntp-server nil
-  "Specify a default NNTP server.
-This variable should be defined in paths.el, and should never be set
-by the user.
-If you want to change servers, you should use `gnus-select-method'.
-See the documentation to that variable.")
 
 (defvar gnus-backup-default-subscribed-newsgroups
   '("news.announce.newusers" "news.groups.questions" "gnu.emacs.gnus")


I'm still bombing in two places:
While compiling toplevel forms in file /usr/lib/xemacs/rgnus-0.01/lisp/earcon.el:
  !! End of stream ((#<buffer " *Compiler Input*">))

I can't figure this one out, since earcon.el hasn't changed in several
versions (and omits the patch I recently submitted :-( to boot).

Also this code is definitely incorrect:
nndoc.el:
(defun nndoc-add-type (definition &optional position)  
  "Add document DEFINITION to the list of nndoc document definitions.
If POSITION is nil or `last', the definition will be added
as the last checked definition, if t or `first', add as the
first definition, and if any other symbol, add after that
symbol in the alist."        
  (cond                                                             
   ((or (null position) (eq position 'last))                              
    (setq nndoc-type-alist (nconc nndoc-type-alist (list definition))))
   ((or (eq position t) (eq position 'first))
    (push definition nndoc-type-alist))             
   (t                                                                  
    (let ((list (memq (assq position nndoc-type-alist))))
                 ^^^^
      (unless list                                              
        (error "No such position: %s" position))                 
      (setcdr list (cons definition (cdr list)))))))


memq requires two parameters and not one.  This is a new function, so
I'm can't tell from past code what this is supposed to accomplish
exactly.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

Re: Red Gnus v0.1 is released

[Sudish Joseph]

In article <m2enltmcf7.fsf@deanna.miranova.com>,
Steven L Baur <steve@miranova.com> writes:
> Sudish's patch didn't help me at all :-(.

Ooooops, I did M-x diff-backup after visiting the file for a second
time and making another change (unnecessary, I just wanted the defvars
of the select-method's together in one place).  Was in too much of a
hurry to look at the diff, apologies. :( I should add gnus to my CVS
tree to avoid such blunders, I guess, especially now that's it's alpha
season again (joy!).

Update: the gnus-async stuff seems to get confused as to which o/p
belongs to which command.  I'm getting articles containing NNTP o/p as
well as empty article buffers.

-Sudish

Patch for async fetch munging articles bug

[Sudish Joseph]

Sudish Joseph <sudish@mindspring.com> writes:
> Update: the gnus-async stuff seems to get confused as to which o/p
> belongs to which command.  I'm getting articles containing NNTP o/p as
> well as empty article buffers.

Here's what I think is a fix for this.  I say "think" coz it's like
the 10th "fix" or so, each prior one having failed to me "thinking" it
was correct.  You have been warned.

The problem is basically in #'nntp-process-filter, which assumes that
by searching -backwards- from the end for the wait-for'ed string, it
won't skip over other instances of the same string.  However, multiple
replies can pour in by the time that filter kicks in.  (I'm not too
sure about that last statement, it only seems to happen for the very
first group you visit.)

Fixing this seemed too hard, since one would have to tag replies in
some fashion to ensure that they're handed over to the correct
callback function.  So I fixed it in gnus-async, where you generate
the callback.  (Very cool code, Lars.)

There's still some weirdness left here, I think.  My brain, uh, seat
cushion is fried, though, so I'm not digging further tonight.

This was a b*tch to debug -- edebug craps out on backquoted forms
inside of defuns and is a total lose for those cool callbacks you're
generating.

-Sudish

PS: For a gnus-reopen-all-connections command, does it suffice to
delete all process buffers in nntp-connection-alist?  I'd really like
to have this available since I use a demand dialer to manage my
connection.


Wed Jul 31 03:09:23 1996  Sudish Joseph  <sudish@mindspring.com>

	* gnus-async.el (gnus-async-prefetch-article): Search forward for
        end of article from saved marker; multiple articles (and even nntp
	reply codes) may be present in the async buffer.  Signal failures
        in filters via explicit 'message or they'll be trapped and lost.



--- gnus-async.el	Wed Jul 31 03:19:54 1996
+++ gnus-async.el	Wed Jul 31 03:19:54 1996
@@ -101,8 +101,12 @@
 		 `(lambda (arg)
 		    (save-excursion
 		      (gnus-async-set-prefetch-buffer)
+		      (goto-char ,mark)
+		      (unless (re-search-forward "\r\n\\.\r\n" nil t)
+			(message "bogon in gnus-async-prefetch-article!")
+			(ding))
 		      (push (list ',(intern (format "%s-%d" group article))
-				  ,mark (set-marker (make-marker) (point-max))
+				  ,mark (set-marker (make-marker) (point))
 				  ,group ,article)
 			    gnus-async-article-alist)
 		      (when (gnus-buffer-live-p ,summary)

Re: Patch for async fetch munging articles bug

[Lars Magne Ingebrigtsen]

Sudish Joseph <sudish@mindspring.com> writes:

> The problem is basically in #'nntp-process-filter, which assumes that
> by searching -backwards- from the end for the wait-for'ed string, it
> won't skip over other instances of the same string.  However, multiple
> replies can pour in by the time that filter kicks in.  (I'm not too
> sure about that last statement, it only seems to happen for the very
> first group you visit.)

I don't think that should happen.  The prefetching is serialized, and
the only thing that happens on that particular connection is the
article prefetch...

But I've also seen odd things happening, but whenever I edebug to try
to see what's going on, everything works perfectly.  

Anyways, I think I'll rewrite the nntp function that currently uses
process filters to use `after-change-function' instead.  That'll
probably be more efficient and will produce less garbage strings.

> PS: For a gnus-reopen-all-connections command, does it suffice to
> delete all process buffers in nntp-connection-alist? 

Yup.

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

Re: Red Gnus v0.1 is released

[Lars Magne Ingebrigtsen]

Sudish Joseph <sudish@mindspring.com> writes:

> How about defvaring all keymaps to empty keymaps in gnus-start or
> someplace equally early and having the actual keymap setup code
> checking to see if an entry already exists bwefore adding one?  

That's a good idea.  Fix in Red Gnus v0.2.

> But, this can cause problems if you do something that requires
> bandwidth in itself (for instance, hitting "g" locks me up solid coz
> my PPP link is being used for the async fetch -- the b/w won't even be
> shared well coz the SYN's will take a longish time to get through to
> establish the new connection).  Maybe some kind of scheduler or
> limiter for the async stuff?  Hmm, maybe just using one connection for
> all NNTP I/O would suffice since this would serialize requests
> automatically, all that'd be needed is intelligent prioritized
> scheduling (with preemption based on priority) of commands over that
> one link.  

Well, that leads to all sorts of different problems.  Say that the
async fetch has started to fetch a Huge article, and then you decide
that you want to read some other article.  Since there is no way to
terminate a command that has already been sent, this means that you'll
have to wait until the async fetch has ended.  When using two
connections, that just means that your PPP link will have to transfer
the two articles at the same time, which is no problem.  Somewhat
slower, but no problem.

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

Re: Red Gnus v0.1 is released

[Carsten Leonhardt]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

Lars> ... and we're off.
Lars> Expect major bugs in this release.  Not for the faint of heart.

I just tried it. I had to remove some hooks for bbdb and tm, then it
started through, showing me the red gnus logo :)

Well, my question is, is it sensible to start bug-reporting now? I
just wonder, because I had an error with about every third thing I
tried...  so I guess you are finding enough bugs yourself for now.

Bye,
  Leo

Re: Red Gnus v0.1 is released

[Sudish Joseph]

In article <m3ybk1cjdt.fsf@arioch.tng.oche.de>,
Carsten Leonhardt <leo@arioch.tng.oche.de> writes:
> I just tried it. I had to remove some hooks for bbdb and tm, then it
> started through, showing me the red gnus logo :)

This was the hack I mentioned in my earlier mail.  It'll remove your
BBDB problems.  It'll probably remove your tm problems as well, coz
I'm having none.  

It's a hack coz it defeats the purpose of splitting gnus.el, IMO.

-Sudish

*** gnus-start.el~	Tue Jul 30 23:36:57 1996
--- gnus-start.el	Tue Jul 30 23:36:58 1996
***************
*** 32,37 ****
--- 32,38 ----
  (require 'gnus-spec)
  (require 'gnus-range)
  (require 'message)
+ (require 'gnus-sum)
  
  (defvar gnus-secondary-servers nil
    "*List of NNTP servers that the user can choose between interactively.

Re: Red Gnus v0.1 is released

[Sudish Joseph]

In article <m2wwzl146b.fsf@atreides.erehwon.org>,
Sudish Joseph <sudish@mindspring.com> writes:
> It's a hack coz it defeats the purpose of splitting gnus.el, IMO.

It's a hack coz it earns you a "max-specpdl-size exceeded" error if
you use it. :(

The only workaround for the keymaps I can find is to put a (require
'gnus-sum) on gnus-startup-hook *before* either of tm/bbdb.  

-Sudish  

Re: Red Gnus v0.1 is released

[Christian Viken]

while compiling red gnus v0.01 with emacs 19.31.1 IRIX 5.3 SGI Indy:

While compiling toplevel forms in file earcon.el:
  !! End of file during parsing

While compiling the end of the data in file gnus-logic.el:
  ** the function parse-time-string is not known to be defined.

While compiling the end of the data in file gnus-sum.el:
  ** the function gnus-async-prefetch-remove-group is not known to be defined.

While compiling the end of the data in file nndb.el:
  ** The following functions are not known to be defined: 
    nntp-possibly-change-server, nntp-encode-text,
    nntp-send-region-to-server, nntp-wait-for-response

While compiling nndoc-set-delims in file nndoc.el:
  ** assignment to free variable guess
While compiling nndoc-add-type:
  ** memq called with 1 arg, but requires 2

While compiling toplevel forms in file parse-time.el:
  ** reference to free variable elt
  ** reference to free variable val

-------------------------
While starting red gnus:

no errors

-------------------------
While posting to Usenet with red gnus:
After pressing C-c-c:

Sending...
Symbol's function definition is void: nntp-request-post

After this: no reaction. The article is not sent.

-Chris
-- 
_____________________________________________________________
Christian Viken (IRC: Zakka)         | WWW administrator NTNU
Email: chrisvik@itea.ntnu.no         | www-admin@www.ntnu.no
URL  : http://www.ntnu.no/~chrisvik/ | http://www.ntnu.no/