request: commands for subsribe/unsubsribe from/to mailing lists

request: commands for subsribe/unsubsribe from/to mailing lists

[Jari Aalto+list.ding]

    Hi,

    I just got back from vacation and noticed that my forwarding service
    had had troubles. I'm subsribed to several lists and most of
    the MLM managers that run the lists had sent me probes to determine
    that my address was not alive any more and terminated the 
    list subsribtion.
    
    It was kinda annoying to recall from old messages what were the
    exact conditions and addresses to re-subscribe back to the lists.

    Would if be possible to have 2 new commands to summary buffer which would:

        - unsubsribe from mailing list (eg. when taking a long leave)
        - subsribe to mailing list
    
    I'm assuming that Group parameter had entry defining how to 
    subsribe to the list by telling what are the header/body values and
    to which address the request should be sent. Something like

         (subscribe
          (from . "<jari.aalto@poboxes.com>")
          (to . "<LISTSERV@peach.ease.lsoft.com>")
          (body "subscribe SPAM-L Jari Aalto"))

    And something similar for unsubscribe.

    jari

Re: request: commands for subsribe/unsubsribe from/to mailing lists

[Jason L Tibbitts III]

>>>>> "JA" ==   <jari.aalto@poboxes.com> writes:

JA> I'm assuming that Group parameter had entry defining how to zubsribe to
JA> the list by telling what are the header/body values and to which
JA> address the request should be sent.

Actually there is an RFC detailing a set of headers used to communicate
this information.  That would be RFC2369.  What it comes down to is that
all/some/periodic messages from a list can include headers with
instructions on dealing with the list server, and messages can include a
unique identifier that designates messages from the list even if the server
moves.  The MUA is supposed to save the instructions in the headers and use
them when presenting the user with some list manipulation functionality.

Note that this RFC is pretty new and I'm pretty lame, so this list does not
yet implement these headers.  If someone feels like working on this stuff
in Gnus, I'll be happy to set the list server up to give you something to
test.

 - J<

Re: request: commands for subsribe/unsubsribe from/to mailing lists

[Lars Magne Ingebrigtsen]

<jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

> Would if be possible to have 2 new commands to summary buffer which would:
> 
> - unsubsribe from mailing list (eg. when taking a long leave)
> - subsribe to mailing list
> 
> I'm assuming that Group parameter had entry defining how to 
> subsribe to the list by telling what are the header/body values and
> to which address the request should be sent. Something like
> 
> (subscribe
> (from . "<jari.aalto@poboxes.com>")
> (to . "<LISTSERV@peach.ease.lsoft.com>")
> (body "subscribe SPAM-L Jari Aalto"))
> 
> And something similar for unsubscribe.

I've added this to the todo list.  But there should be commands to
create these group params automatically.

I envision putting point over the address of the list and typing `M-x
gnus-add-mailing-list', which would then ask (and/or guess) what type
of mailing list it is (LISTSERV, Majordomo, etc.) and then prompt
away, giving reasonable defaults, and then adding this to the params.

Anyone want to implement this?  You'd have to know the un/subscription
rules for most major mailing list software.

Hm.  Perhaps commands for un/suspending lists would also be nice?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: request: commands for subsribe/unsubsribe from/to mailing lists

[Lars Magne Ingebrigtsen]

Jason L Tibbitts III <tibbs@hpc.uh.edu> writes:

> Actually there is an RFC detailing a set of headers used to communicate
> this information.  That would be RFC2369.

Hm.  Well, RFC2369 would work, I guess.  What they do is define a slew
of new headers that contains URL(s).  Like:

     List-Subscribe: <mailto:list@host.com?subject=subscribe>

Eh.  Well, why not?  Doesn't everyone read mail with a web browser?
Huh? 

Anyway.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: request: commands for subsribe/unsubsribe from/to mailing lists

[Bud Rogers]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I've added this to the todo list.  But there should be commands to
> create these group params automatically.
> 
> I envision putting point over the address of the list and typing `M-x
> gnus-add-mailing-list', which would then ask (and/or guess) what type
> of mailing list it is (LISTSERV, Majordomo, etc.) and then prompt
> away, giving reasonable defaults, and then adding this to the params.


Oh, that would be so nice.  I'm just going through the great change of
address battle.  Some of list software is positively obtuse.  Moderately
easy to subscribe to, moderately difficult to unsubscribe from, and totally
frustrating to change to a new address, especially when you've already
moved.

There's a pizza in this, my treat.

-- 

Bud Rogers <budr@sirinet.net> 
  formerly <budr@tanet.net>

Re: request: commands for subsribe/unsubsribe from/to mailing lists

[William M. Perry]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Jason L Tibbitts III <tibbs@hpc.uh.edu> writes:
> 
> > Actually there is an RFC detailing a set of headers used to communicate
> > this information.  That would be RFC2369.
> 
> Hm.  Well, RFC2369 would work, I guess.  What they do is define a slew
> of new headers that contains URL(s).  Like:
> 
>      List-Subscribe: <mailto:list@host.com?subject=subscribe>
> 
> Eh.  Well, why not?  Doesn't everyone read mail with a web browser?
> Huh? 
> 
> Anyway.

  how absolutely #!%@!ing worthless.  I really yearn for the good old
days.  I remember when chris wilson and I were floored in July '94 by the
fact that some airplane flying around seattle's big fourth of july pary
area had a URL on it.  We laughed that nobody would know what it was...

   Ahhh, if only. :)

-Bill P.

Marking new unread articles differently?

[Matt Simmons]

I can't be the only one who has obscene numbers of unread messages
rotting away in my mailbox.  This causes me to lose new messages,
especially when the appear as part of a thread headed by previously
unread messages.

Is there any way to have the messages that have appeared since the
last time the spool was inc'd displayed in a different face in the
Summary Buffer?  This would make it easier to differentiate between
old and new unread messages.

Thanks

Matt

-- 
     Matt Simmons  -  simmonmt@acm.org  -  http://www.netcom.com/~simmonmt
	 Everyone has a photographic memory. Some just don't have film.

Re: Marking new unread articles differently?

[Lars Magne Ingebrigtsen]

Matt Simmons <simmonmt@acm.org> writes:

> I can't be the only one who has obscene numbers of unread messages
> rotting away in my mailbox.  This causes me to lose new messages,
> especially when the appear as part of a thread headed by previously
> unread messages.

Well -- don't you want to read messages earlier in the thread before
messages later in the thread?

> Is there any way to have the messages that have appeared since the
> last time the spool was inc'd displayed in a different face in the
> Summary Buffer?  This would make it easier to differentiate between
> old and new unread messages.

I think it sounds like you really want an unthreaded mail group
summary display.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Marking new unread articles differently?

[SL Baur]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes in ding@gnus.org:

> Matt Simmons <simmonmt@acm.org> writes:
 ...
>> Is there any way to have the messages that have appeared since the
>> last time the spool was inc'd displayed in a different face in the
>> Summary Buffer?  This would make it easier to differentiate between
>> old and new unread messages.

> I think it sounds like you really want an unthreaded mail group
> summary display.

Can this be done with proper fiddling to `gnus-summary-highlight'?
Is it possible to have group-specific `gnus-summary-highlight' specs?

Re: Marking new unread articles differently?

[Harry Putnam]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Matt Simmons <simmonmt@acm.org> writes:
> 
> > I can't be the only one who has obscene numbers of unread messages
> > rotting away in my mailbox.  This causes me to lose new messages,
> > especially when the appear as part of a thread headed by previously
> > unread messages.
> 
> Well -- don't you want to read messages earlier in the thread before
> messages later in the thread?
> 
> > Is there any way to have the messages that have appeared since the
> > last time the spool was inc'd displayed in a different face in the
> > Summary Buffer?  This would make it easier to differentiate between
> > old and new unread messages.
> 
> I think it sounds like you really want an unthreaded mail group
> summary display.

Something along this same vein:

I like to have the summary displayed with hidden threads, and have set
up the `gnus-summary-line-format' to show the number of messages in a
thread. To me, this makes it easier to get a quick overview of the
summary. Scroll down to something interesting and start using 'n'
which will open the threads and find the new articles.

If you have the default view of only new articles, but have a number
of 'ticked' articles also in the display then a new message can hide
behind a ticked message.

I'd like to be able to notice any new articles with out opening the
threads with 'T S' and with out using 'n' till I want it.

So how would it work to have any thread containing a new message, show
the 'unread face' even if some messages in the thread are already read
but ticked then when the thread is opened the ticked ones show
'ticked face'  and the unread show unread normally.


-- 

Harry Putnam  reader@newsguy.com

Re: Marking new unread articles differently?

[Eze Ogwuma]

Matt Simmons <simmonmt@acm.org> writes:

> I can't be the only one who has obscene numbers of unread messages
> rotting away in my mailbox.

You're not the only one.

[...]

> Is there any way to have the messages that have appeared since the
> last time the spool was inc'd displayed in a different face in the
> Summary Buffer? 

Or perhaps the "%" mark could be used.

> This would make it easier to differentiate between old and new
> unread messages.

I'd like to see a feature like this too.

-- 
Eze Ogwuma

Re: Marking new unread articles differently?

[Lars Magne Ingebrigtsen]

SL Baur <steve@xemacs.org> writes:

> Can this be done with proper fiddling to `gnus-summary-highlight'?

Well, now that I think of it, `nnmail-split-history' has a record of
newly arrived articles, which could be used.

> Is it possible to have group-specific `gnus-summary-highlight' specs?

Sure; no problem.  Can be set in group params or
gnus-summary-mode-hook. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Marking new unread articles differently?

[Mike McEwan]

Matt Simmons <simmonmt@acm.org> writes:

> I can't be the only one who has obscene numbers of unread messages
> rotting away in my mailbox.  This causes me to lose new messages,
> especially when the appear as part of a thread headed by previously
> unread messages.
> 
> Is there any way to have the messages that have appeared since the
> last time the spool was inc'd displayed in a different face in the
> Summary Buffer?  This would make it easier to differentiate between
> old and new unread messages.
> 
  I've been hacking a bit at the gnus source and now have all newly
  downloaded headers in all my groups flagged with a secondary mark
  "?N" when I enter the summary buffer. This mark can be used by all
  the usual summary limiting commands. I've also got some group
  selection functions that allow me to show only threads with `new'
  headers or only `new' headers when entering a group. Optionally, the
  number of newly downloaded headers for a group can be displayed in
  the group buffer, although I don't know how much sense this makes
  for those who read their news online.

  Another function I find useful is having my `agent' groups flagged
  with a "?>" whenever articles have been downloaded via the use of
  `%' (gnus-downloadable-mark). I keep marking articles for download
  and then never reading them having forgotten. As with `new' articles
  I can select these articles when entering a group and use summary
  limiting commands on them.

  If anyone's interested I'll post my current patches to this
  list. Although the code seems fairly stable, it'd be good if some
  others could give it the once over and help me remove the `kludge
  factor' :-). As intimated above, I read my news *offline* via the
  `agent' and so I've yet to verify what potential damage my code can
  do in an *online* situation.

-- 
Mike.

Re: Marking new unread articles differently?

[Jari Aalto+list.ding]

| 1998-08-16 Mike McEwan <mike@lotusland.demon.co.uk> list.ding
[exellent features, flagged messages ]

|   If anyone's interested I'll post my current patches to this
|   list. Although the code seems fairly stable, it'd be good if some
|   others could give it the once over and help me remove the `kludge
|   factor' :-). As intimated above, I read my news *offline* via the
|   `agent' and so I've yet to verify what potential damage my code can
|   do in an *online* situation.

Oh, please do. Sounds like a *very* usefull features.
jari

Master or slave??

[Andy Eskilsson]

As the careful person I am I want to know if it is the 'master' GNUS I
am getting in touch with, or the slave.. I am afraid of the whips and
leather..

Are there any good way to determine which of the gnusae that are
running in my emacs?

	/andy

Re: Master or slave??

[Jari Aalto+list.ding]

|Mon 1998-08-17 Kurt Swanson <ksw@dna.lth.se> list.ding
| Andy Eskilsson <andy.eskilsson@telelogic.se> writes:
| > As the careful person I am I want to know if it is the 'master' GNUS I
| > am getting in touch with, or the slave.. I am afraid of the whips and
| > leather..
| 
| > Are there any good way to determine which of the gnusae that are
| > running in my emacs?
| 
| C-h v gnus-slave RET

Could we get this displayed in the Group modeline by default?
Eg. string "Slave" after "Plugged"

jari

Re: Master or slave??

[Lars Magne Ingebrigtsen]

<jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

> Could we get this displayed in the Group modeline by default?
> Eg. string "Slave" after "Plugged"

Ooh.  That's kinda indecent, isn't it?

I've added this to Gnus v5.6.38.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Master or slave??

[Andy Eskilsson]

/ <jari.aalto@poboxes.com> (Jari Aalto+list.ding) wrote:
| 
| Could we get this displayed in the Group modeline by default?
| Eg. string "Slave" after "Plugged"

I am still waiting for the 'Master' gnus-splash screen containing a
Gnu with a whip, and the 'Slave' splash-screen with a Gnu in
chains.. or something similar.. 

	/andy

Re: Marking new unread articles differently?

[Mike McEwan]

<jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

> Oh, please do. Sounds like a *very* usefull features.
> jari

  Wow, one interested person :-)

  Well here's the patch (against gnus-5.6.37). Sorry, I reckon it's
got quite big now.

  Anyways, if you apply it and you're `agentized' (I don't think it's
of much benefit to those who read online all the time), just add:

(setq gnus-mark-new-headers 't)
(setq gnus-mark-downloaded 't)

  to your ~/.gnus or whatever and a `%a' somewhere in your
`gnus-group-line-format' - probably best at the end - it's a ten
character-width field. To view only threads with new/downloaded
headers do a `C-M-n', only new/downloaded do `C-u C-M-n'. All
new/downloaded marks are removed when exiting a group, optionally
they can be removed with `G n' (remove marks from this group), or `G
N' (remove marks from all groups). See the minimal doc in the patch
text for clues. `new' marks will be present for *all* unread articles
the *first* time with `gnus-mark-new-headers, I think.

  A couple of little things not covered in my previous mail to this
list are the group parameter `dont-copy-marks' which when added to a
group does exactly what it implies in respect of articles copied
from other groups - no marks, apart from a `new' mark, are copied
across. Also, sometimes when I've had articles queued in my `drafts'
group ready for sending, I forget to send them because the `nndraft'
group line doesn't show in the group buffer until I do a `g'.
There's a couple of little kludges in here to make these groups show
when there's something in them.

  I've probably gone a little wild here. You know how it is - start
with a little function here, a tweak there :-). My functions aren't
prefixed with `my-gnus..' either, but there just weren't enough
hooks! Please note I haven't really used this with offline news
reading, it's still a little rough I think. I'd appreciate hearing
what folks think. I'll provide some more doc if folks are
confused.Lars d'you think we (the off-liners anyway) could have
something like this?

-- 
Mike.

diff -ur gnus-orig/lisp/gnus-agent.el gnus/lisp/gnus-agent.el
--- gnus-orig/lisp/gnus-agent.el	Sun Aug 16 17:59:43 1998
+++ gnus/lisp/gnus-agent.el	Sun Aug 16 21:27:47 1998
@@ -333,7 +333,13 @@
      (concat "^" (regexp-quote mail-header-separator) "\n"))
     (replace-match "\n")
     (gnus-agent-insert-meta-information 'mail)
-    (gnus-request-accept-article "nndraft:queue")))
+    (gnus-request-accept-article "nndraft:queue")
+    (save-excursion
+      (set-buffer gnus-group-buffer) 
+      (gnus-group-update-group "nndraft:queue")
+      (save-excursion
+	(gnus-group-goto-group "nndraft:queue" t)
+	(gnus-group-get-new-news-this-group 1 t)))))
 
 (defun gnus-agent-insert-meta-information (type &optional method)
   "Insert meta-information into the message that says how it's to be posted.
@@ -782,7 +788,7 @@
 	  (gnus-agent-enter-history "last-header-fetched-for-session"
 				    (list (cons group (nth (- (length  articles) 1) articles)))
 				    (gnus-time-to-day (current-time)))
-	t)))))
+	  t)))))
 
 (defsubst gnus-agent-copy-nov-line (article)
   (let (b e)
@@ -801,7 +807,7 @@
     (set-buffer nntp-server-buffer)
     (erase-buffer)
     (insert-file-contents file)
-    (goto-char (point-min))
+    (goto-char (point-max))
     (if (or (= (point-min) (point-max))
 	    (progn
 	      (forward-line -1)
@@ -892,7 +898,7 @@
 	gnus-newsgroup-dependencies gnus-newsgroup-headers
 	gnus-newsgroup-scored gnus-headers gnus-score
 	gnus-use-cache articles score arts
-	category predicate info marks score-param)
+	category predicate info marks score-param downloaded)
     ;; Fetch headers.
     (when (and (or (gnus-active group) (gnus-activate-group group))
 	       (setq articles (gnus-list-of-unread-articles group))
@@ -925,13 +931,25 @@
       (when arts
 	(gnus-agent-fetch-articles group arts)))
     ;; Perhaps we have some additional articles to fetch.
-    (setq arts (assq 'download (gnus-info-marks
-				(setq info (gnus-get-info group)))))
+    (setq info (gnus-get-info group))
+    (setq arts (assq 'download (gnus-info-marks info)))
     (when (cdr arts)
       (gnus-agent-fetch-articles
        group (gnus-uncompress-range (cdr arts)))
-      (setq marks (delq arts (gnus-info-marks info)))
-      (gnus-info-set-marks info marks))))
+      (if gnus-mark-downloaded
+	  (if (setq downloaded (assq 'downloaded 
+				     (gnus-info-marks info)))
+	      (progn
+		(setq downloaded (cons 'downloaded
+				       (gnus-add-to-range 
+					(cdr downloaded) (cdr arts))))
+		(setq marks (delq arts (gnus-info-marks info))))
+	    (setcar arts 'downloaded))
+	(gnus-info-set-marks info marks)))
+    ;; Update group line to indicate the actual number (minus cancellations)
+    ;; of headers downloaded and whether any articles marked with
+    ;; `gnus-downloadable-mark' were downloaded.
+    (gnus-group-update-group group t)))
 
 ;;;
 ;;; Agent Category Mode
diff -ur gnus-orig/lisp/gnus-group.el gnus/lisp/gnus-group.el
--- gnus-orig/lisp/gnus-group.el	Sun Aug 16 17:59:44 1998
+++ gnus/lisp/gnus-group.el	Tue Aug 18 23:56:48 1998
@@ -160,6 +160,7 @@
 %n    Select from where (string)
 %z    A string that look like `<%s:%n>' if a foreign select method is used
 %d    The date the group was last entered.
+%a    The number of newly arrived headers since the group was last selected.
 %u    User defined specifier.  The next character in the format string should
       be a letter.  Gnus will call the function gnus-user-format-function-X,
       where X is the letter following %u.  The function will be passed the
@@ -347,6 +348,12 @@
   :group 'gnus-group-visual
   :type 'character)
 
+(defcustom gnus-downloaded-mark ?*
+  "Mark used for articles that have been newly
+downloaded via `gnus-downloadable-mark' - `%'."
+  :group 'gnus-summary-marks
+  :type 'character)
+
 ;;; Internal variables
 
 (defvar gnus-group-sort-alist-function 'gnus-group-sort-flat
@@ -395,6 +402,7 @@
     (?z gnus-tmp-news-method-string ?s)
     (?m (gnus-group-new-mail gnus-tmp-group) ?c)
     (?d (gnus-group-timestamp-string gnus-tmp-group) ?s)
+    (?a (gnus-new-headers-string gnus-tmp-group) ?s)
     (?u gnus-tmp-user-defined ?s)))
 
 (defvar gnus-group-mode-line-format-alist
@@ -426,6 +434,7 @@
     "\r" gnus-group-select-group
     "\M-\r" gnus-group-quick-select-group
     [(meta control return)] gnus-group-select-group-ephemerally
+    "\M-\C-n" gnus-group-select-group-new
     "j" gnus-group-jump-to-group
     "n" gnus-group-next-unread-group
     "p" gnus-group-prev-unread-group
@@ -512,6 +521,8 @@
     "w" gnus-group-make-web-group
     "r" gnus-group-rename-group
     "c" gnus-group-customize
+    "n" gnus-group-clear-new-marks
+    "N" gnus-group-clear-new-marks-all
     "\177" gnus-group-delete-group
     [delete] gnus-group-delete-group)
 
@@ -584,6 +595,10 @@
        ["Catch up" gnus-group-catchup-current (gnus-group-group-name)]
        ["Catch up all articles" gnus-group-catchup-current-all
 	(gnus-group-group-name)]
+       ["Remove new article marks" gnus-group-clear-new-marks
+	(when gnus-mark-new-headers (gnus-group-group-name))]
+       ["Remove *all* new marks" gnus-group-clear-new-marks-all
+	(when gnus-mark-new-headers t)]
        ["Check for new articles" gnus-group-get-new-news-this-group
 	(gnus-group-group-name)]
        ["Toggle subscription" gnus-group-unsubscribe-current-group
@@ -1253,8 +1268,15 @@
   (get-text-property (gnus-point-at-bol) 'gnus-unread))
 
 (defun gnus-group-new-mail (group)
-  (if (nnmail-new-mail-p (gnus-group-real-name group))
-      gnus-new-mail-mark
+  (if (not (gnus-news-group-p group))
+      (if (nnmail-new-mail-p (gnus-group-real-name group))
+	  gnus-new-mail-mark
+	? )
+    (gnus-group-downloaded group)))
+
+(defun gnus-group-downloaded (group)
+  (if (assq 'downloaded (gnus-info-marks (gnus-get-info group)))
+      gnus-downloaded-mark
     ? ))
 
 (defun gnus-group-level (group)
@@ -3369,6 +3391,112 @@
     (if (not time)
 	""
       (gnus-time-iso8601 time))))
+
+;;;
+;;; `new' header mark functions  
+;;;
+
+(defun gnus-new-headers-string (group)
+  "Return a space padded string of numerics of the form `nnnn(nnnn)'
+where the digits preceding the `(' indicate the number of `new'
+headers that have arrived in the group since the last time it was
+selected. The suffixing space padded `(nnnn)' should only be returned
+for genuine newsgroups, and indicates the number of potentially
+downloadable headers still on the news-server (e.g. after a `g' in the
+group buffer).
+  `n/a' is returned for `nndraft' groups as indicating `new' headers
+doesn't make much sense. Perhaps there are a few other non-applicable
+backends?"
+  (if (eq (car (gnus-find-method-for-group group))
+	  'nndraft)
+      " n/a"
+    (let* ((info (gnus-get-info group))
+	   (marks (gnus-info-marks info))
+	   (max (cdr (gnus-active group)))
+	   (last (gnus-group-get-parameter group 'last))
+	   (new (gnus-uncompress-range (cdr (assq 'new marks))))) 
+      ;; Group is perhaps not `active'.
+      (when (not max) (setq max 0))
+      (if (and new last) 
+	  (if (gnus-news-group-p group)
+	      (format "%4s(%4s)" (length new) (- max last))
+	    (format "%4s" (length new)))
+	(progn
+	  (if (and last (gnus-news-group-p group)) 
+	      ;; No new headers, so just indicate those potentially 
+	      ;; downloadable.
+	      (format "%4s(%4s)" "0" (- max last))
+	    (if (gnus-news-group-p group)
+	      (format "%4s(%4s)" "0" "0")
+	    ;; Non newsgroup with no new headers.  
+	    "   0")))))))
+
+(defun gnus-group-clear-new-marks-all ()
+  "Clear `new' marks from all groups in `gnus-newsrc-alist'."
+  (interactive)
+  (gnus-group-clear-new-marks t))
+
+(defun gnus-group-clear-new-marks (&optional n)
+  "Nullify all `new' header marks in the current newsgroup.
+If N is numeric, marks will be removed from the next N groups.
+If N is non-nil and non-numeric, clear marks from all groups."
+  (interactive "P")
+  (if (or (numberp n) (null n))
+      (let ((groups (gnus-group-process-prefix n)))
+	(unless groups (error "No groups selected"))
+	(while groups
+	  (let*
+	      ((info (gnus-get-info (car groups)))
+	       (marks (gnus-info-marks info)))
+	    (gnus-group-remove-mark (car groups))
+	    (if (>= (gnus-group-group-level) gnus-level-zombie)
+		(gnus-message 2 "Dead groups can't be cleared of marks")
+	      (progn
+		(setq marks (delq (assq 'new marks) marks))
+		(gnus-info-set-marks info marks t))
+	      (gnus-group-update-group-line))
+	    (setq groups (cdr groups))))
+	(gnus-group-next-unread-group 1)
+	(gnus-message 4 "\"new\" marks cleared"))
+    (let ((groups (mapcar 'car (cdr gnus-newsrc-alist))))
+      (while groups
+	(unless (eq (car (gnus-find-method-for-group (car groups)))
+		    'nndraft)
+	  (let*
+	      ((info (gnus-get-info (car groups)))
+	       (marks (gnus-info-marks info)))
+	    (setq marks (delq (assq 'new marks) marks))
+	    (gnus-info-set-marks info marks t))
+	  (gnus-group-update-group (car groups) t))
+	(setq groups (cdr groups)))
+      (gnus-message 4 "\"new\" marks cleared for all groups"))))
+
+(defun gnus-group-select-group-new (&optional no-threads)
+  "Select this newsgroup asking for threads with new
+headers and/or articles that have been newly downloaded via
+`gnus-downloadable-mark'. If NO-THREADS is non-nil, only
+`new' and/or `downloaded' articles will be displayed."
+  (interactive "P")
+  (let*
+      ((group (gnus-group-group-name))
+       (info (gnus-get-info group))
+       (marks (gnus-info-marks info))
+       (gnus-fetch-old-headers (if no-threads nil t))
+       (new (gnus-uncompress-range (cdr (assq 'new marks))))
+       (downloaded (gnus-uncompress-range (cdr (assq 'downloaded marks)))))
+;      (num (+ (length new) (length downloaded))))
+    (when (not gnus-agent)
+	(setq new (gnus-uncompress-range
+		   (cons
+		   (1+ (gnus-group-get-parameter group 'last))
+		   (cdr (gnus-active group))))))
+    (if (or new downloaded)
+	(progn
+	  (when downloaded
+	    (setq new (append downloaded new)))
+	  (gnus-group-read-group nil t nil new)) 
+      (error "No new messages in group"))))
+
 
 (provide 'gnus-group)
 
diff -ur gnus-orig/lisp/gnus-int.el gnus/lisp/gnus-int.el
--- gnus-orig/lisp/gnus-int.el	Tue Aug 11 18:53:51 1998
+++ gnus/lisp/gnus-int.el	Mon Aug 17 20:57:18 1998
@@ -278,11 +278,46 @@
   "Request headers for ARTICLES in GROUP.
 If FETCH-OLD, retrieve all headers (or some subset thereof) in the group."
   (let ((gnus-command-method (gnus-find-method-for-group group)))
-    (if (and gnus-use-cache (numberp (car articles)))
-	(gnus-cache-retrieve-headers articles group fetch-old)
-      (funcall (gnus-get-function gnus-command-method 'retrieve-headers)
-	       articles (gnus-group-real-name group)
-	       (nth 1 gnus-command-method) fetch-old))))
+    ;; Need to preserve the return value of `nov' or `headers'
+    ;; from the `retrieve-headers' function before optionally 
+    ;; counting in `new' headers.
+    (prog1
+	(if (and gnus-use-cache (numberp (car articles)))
+	    (gnus-cache-retrieve-headers articles group fetch-old)
+	  (funcall (gnus-get-function gnus-command-method 'retrieve-headers)
+		   articles (gnus-group-real-name group)
+		   (nth 1 gnus-command-method) fetch-old))
+      (when (and gnus-mark-new-headers (eq (car gnus-command-method) 'nntp)
+		 (if gnus-agent gnus-plugged t))
+	(save-excursion
+	  (set-buffer nntp-server-buffer)
+	  (goto-char (point-max))
+	  (let* ((info (gnus-get-info group))
+		 (marks (gnus-info-marks info))
+		 (last (gnus-group-get-parameter group 'last))
+		 new art)
+	    ;; Set `last' if it's not in the group parameters yet.
+	    ;; Everything's new, first time through. 
+	    (when (not last)
+	      (setq last 
+		    (gnus-group-set-parameter group 'last 
+					      (car (gnus-active group)))))
+	    (while (and
+		    (= (forward-line -1) 0)
+		    (> (setq art (read (current-buffer))) last))
+	      (setq new (append new (list art))))
+	    (when new
+	      ;; Allow new header numbers to accumulate if group
+	      ;; has not been selected since the last time headers
+	      ;; were retrieved.
+	      (progn
+		(setq new (gnus-range-add (cdr (assq 'new marks))
+					  (gnus-compress-sequence (nreverse new))))
+		(setq marks (delq (assq 'new marks) marks))
+		(setq marks (append (list (cons 'new new)) marks))
+		(gnus-info-set-marks info marks t))
+	      ;; `last' can now be made ready for next time.
+	      (gnus-group-set-parameter group 'last (cdr (gnus-active group))))))))))
 
 (defun gnus-retrieve-articles (articles group)
   "Request ARTICLES in GROUP."
diff -ur gnus-orig/lisp/gnus-msg.el gnus/lisp/gnus-msg.el
--- gnus-orig/lisp/gnus-msg.el	Sun Aug 16 17:59:45 1998
+++ gnus/lisp/gnus-msg.el	Sun Aug 16 21:27:48 1998
@@ -962,11 +962,31 @@
 		       (concat "^" (regexp-quote mail-header-separator) "$")
 		       nil t)
 		  (replace-match "" t t ))
-		(unless (gnus-request-accept-article group method t)
-		  (gnus-message 1 "Couldn't store article in group %s: %s"
-				group (gnus-status-message method))
-		  (sit-for 2))
-		(kill-buffer (current-buffer))))))))))
+		(let (group-art)
+		  (if (setq group-art (gnus-request-accept-article group method t))
+		      (when gnus-mark-new-headers
+			(let* ((info (gnus-get-info group))
+			       (marks (gnus-info-marks info))
+			       (new (cdr (assq 'new marks))))
+			  (if new
+			      (setq new (gnus-add-to-range new (list (cdr group-art))))
+			    (setq new (list (cdr group-art))))
+			  (setq marks (delq (assq 'new marks) marks))
+			  (setq marks (append (list (cons 'new new)) marks))
+			  (gnus-info-set-marks info marks t))
+			(save-excursion
+			  (set-buffer gnus-group-buffer) 
+			  (gnus-group-update-group group)
+			  (save-excursion
+			    (gnus-group-goto-group group t)
+			    (gnus-group-get-new-news-this-group 1 t)))
+			;; `last' can now be made ready for next time.
+			(gnus-group-set-parameter group 'last
+						  (cdr (gnus-active group))))
+		    (gnus-message 1 "Couldn't store article in group %s: %s"
+				  group (gnus-status-message method))
+		    (sit-for 2))
+		  (kill-buffer (current-buffer)))))))))))
 
 (defun gnus-inews-insert-gcc ()
   "Insert Gcc headers based on `gnus-outgoing-message-group'."
diff -ur gnus-orig/lisp/gnus-sum.el gnus/lisp/gnus-sum.el
--- gnus-orig/lisp/gnus-sum.el	Sun Aug 16 17:59:46 1998
+++ gnus/lisp/gnus-sum.el	Tue Aug 18 01:19:48 1998
@@ -443,6 +443,11 @@
   :group 'gnus-summary-marks
   :type 'character)
 
+(defcustom gnus-new-mark ?N
+  "*Mark used for articles that are new."
+  :group 'gnus-summary-marks
+  :type 'character)
+
 (defcustom gnus-unsendable-mark ?=
   "*Mark used for articles that won't be sent."
   :group 'gnus-summary-marks
@@ -744,12 +749,17 @@
     ((= mark gnus-unread-mark)
      . gnus-summary-normal-unread-face)
     ((and (> score default) (memq mark (list gnus-downloadable-mark
-					     gnus-undownloaded-mark)))
+					     gnus-undownloaded-mark
+					     gnus-downloaded-mark
+					     gnus-new-mark)))
      . gnus-summary-high-unread-face)
     ((and (< score default) (memq mark (list gnus-downloadable-mark
-					     gnus-undownloaded-mark)))
+					     gnus-undownloaded-mark
+					     gnus-downloaded-mark
+					     gnus-new-mark)))
      . gnus-summary-low-unread-face)
-    ((memq mark (list gnus-downloadable-mark gnus-undownloaded-mark))
+    ((memq mark (list gnus-downloadable-mark gnus-undownloaded-mark
+		      gnus-downloaded-mark gnus-new-mark))
      . gnus-summary-normal-unread-face)
     ((> score default)
      . gnus-summary-high-read-face)
@@ -779,6 +789,16 @@
 The function is called with one parameter, the article header vector,
 which it may alter in any way.")
 
+(defcustom gnus-mark-new-headers nil
+  "*If non-nil, mark `new' headers in summary mode with `gnus-new-mark'."
+  :group 'gnus-summary
+  :type 'boolean)
+
+(defcustom gnus-mark-downloaded nil
+  "*If non-nil, mark `new' headers in summary mode with `gnus-new-mark'."
+  :group 'gnus-summary
+  :type 'boolean)
+
 ;;; Internal variables
 
 (defvar gnus-scores-exclude-files nil)
@@ -930,7 +950,14 @@
   "List of articles in the current newsgroup that can be processed.")
 
 (defvar gnus-newsgroup-undownloaded nil
-  "List of articles in the current newsgroup that haven't been downloaded..")
+  "List of articles in the current newsgroup that haven't been downloaded.")
+
+(defvar gnus-newsgroup-downloaded nil
+  "List of articles in the current newsgroup that have been newly downloaded
+via `gnus-downloadable-mark' - `%'.")
+
+(defvar gnus-newsgroup-new nil
+  "List of articles in the current newsgroup that are new.")
 
 (defvar gnus-newsgroup-unsendable nil
   "List of articles in the current newsgroup that won't be sent.")
@@ -975,7 +1002,8 @@
     gnus-newsgroup-replied gnus-newsgroup-expirable
     gnus-newsgroup-processable gnus-newsgroup-killed
     gnus-newsgroup-downloadable gnus-newsgroup-undownloaded
-    gnus-newsgroup-unsendable
+    gnus-newsgroup-downloaded
+    gnus-newsgroup-new gnus-newsgroup-unsendable
     gnus-newsgroup-bookmarks gnus-newsgroup-dormant
     gnus-newsgroup-headers gnus-newsgroup-threads
     gnus-newsgroup-prepared gnus-summary-highlight-line-function
@@ -2350,6 +2378,8 @@
     (when (gnus-buffer-exists-p gnus-summary-buffer)
       (set-buffer gnus-summary-buffer))
     (let ((gnus-replied-mark 129)
+	  (gnus-new-mark 129)
+	  (gnus-downloaded-mark 129)
 	  (gnus-score-below-mark 130)
 	  (gnus-score-over-mark 130)
 	  (gnus-download-mark 131)
@@ -2407,6 +2437,10 @@
 		(gnus-tmp-replied gnus-replied-mark)
 		((memq gnus-tmp-current gnus-newsgroup-saved)
 		 gnus-saved-mark)
+		((memq gnus-tmp-current gnus-newsgroup-new)
+		 gnus-new-mark)
+		((memq gnus-tmp-current gnus-newsgroup-downloaded)
+		 gnus-downloaded-mark)
 		(t gnus-unread-mark)))
 	 (gnus-tmp-from (mail-header-from gnus-tmp-header))
 	 (gnus-tmp-name
@@ -3755,6 +3789,10 @@
 		    gnus-replied-mark)
 		   ((memq number gnus-newsgroup-saved)
 		    gnus-saved-mark)
+		   ((memq number gnus-newsgroup-new)
+		    gnus-new-mark)
+		   ((memq number gnus-newsgroup-downloaded)
+		    gnus-downloaded-mark)
 		   (t gnus-unread-mark))
 	     gnus-tmp-from (mail-header-from gnus-tmp-header)
 	     gnus-tmp-name
@@ -3917,6 +3955,12 @@
 	      (gnus-get-newsgroup-headers)))
       (gnus-message 5 "Fetching headers for %s...done" gnus-newsgroup-name)
 
+      ;; Workaround to re-appraise the `new' header situation if gnus is
+      ;; not `agentized'.
+      (when (not gnus-agent)
+	(setq gnus-newsgroup-new (gnus-uncompress-range
+				  (cdr (assq 'new (gnus-info-marks info))))))
+
       ;; Kludge to avoid having cached articles nixed out in virtual groups.
       (when cached
 	(setq gnus-newsgroup-cached cached))
@@ -4320,6 +4364,8 @@
 	 (entry (gnus-gethash group gnus-newsrc-hashtb))
 	 (info (nth 2 entry))
 	 (active (gnus-active group))
+	 (marks (gnus-info-marks info))
+	 (new (cdr (assq 'new marks)))  
 	 range)
     (when entry
       (setq range (gnus-compute-read-articles group articles))
@@ -4327,12 +4373,24 @@
 	(set-buffer gnus-group-buffer)
 	(gnus-undo-register
 	  `(progn
-	     (gnus-info-set-marks ',info ',(gnus-info-marks info) t)
+	     (gnus-info-set-marks ',info ',marks t)
 	     (gnus-info-set-read ',info ',(gnus-info-read info))
 	     (gnus-get-unread-articles-in-group ',info (gnus-active ,group))
 	     (gnus-group-update-group ,group t))))
       ;; Add the read articles to the range.
       (gnus-info-set-read info range)
+      ;; Remove Xref'd read articles from 
+      ;; `new' ranges. 
+      (when new
+	(let ((new (gnus-uncompress-range new)))
+	  (while articles
+	    (setq new (delq (car articles) new))
+	    (setq articles (cdr articles)))
+	  (setq marks (delq (assq 'new marks) marks))
+	  (setq marks (append (list 
+			       (cons 'new (gnus-compress-sequence new)))
+			      marks))
+	  (gnus-info-set-marks info marks)))
       ;; Then we have to re-compute how many unread
       ;; articles there are in this group.
       (when active
@@ -5070,6 +5128,10 @@
     ;; Make all changes in this group permanent.
     (unless quit-config
       (gnus-run-hooks 'gnus-exit-group-hook)
+      (when gnus-mark-new-headers
+	(setq gnus-newsgroup-new nil))
+      (when gnus-mark-downloaded
+	(setq gnus-newsgroup-downloaded nil))
       (gnus-summary-update-info)
       ;; Do adaptive scoring, and possibly save score files.
       (when gnus-newsgroup-adaptive
@@ -5992,10 +6054,62 @@
       (let ((data gnus-newsgroup-data)
 	    (marks (if (listp marks) marks
 		     (append marks nil))) ; Transform to list.
-	    articles)
+	    articles switch)
 	(while data
-	  (when (if reverse (not (memq (gnus-data-mark (car data)) marks))
-		  (memq (gnus-data-mark (car data)) marks))
+	  (when (if reverse (and (not (memq (gnus-data-mark (car data)) marks))
+				 (progn
+				   (setq switch t)
+				   (when (memq '?N marks)
+				     (setq switch 
+					   (not (memq 
+						 (gnus-data-number (car data)) 
+						 gnus-newsgroup-new))))
+				   (when (memq '?> marks)
+				     (setq switch 
+					   (not (memq 
+						 (gnus-data-number (car data)) 
+						 gnus-newsgroup-downloaded))))
+				   (when (and switch (memq '?# marks))
+				     (setq switch 
+					   (not (memq 
+						 (gnus-data-number (car data)) 
+						 gnus-newsgroup-processable))))
+				   (when (and switch (memq '?* marks))
+				     (setq switch 
+					   (not (memq 
+						 (gnus-data-number (car data)) 
+						 gnus-newsgroup-cached))))
+				   (when (and switch (memq '?A marks))
+				     (setq switch 
+					   (not (memq 
+						 (gnus-data-number (car data)) 
+						 gnus-newsgroup-replied))))
+				   (when (and switch (memq '?S marks))
+				     (setq switch 
+					   (not (memq (gnus-data-number (car data)) 
+						  gnus-newsgroup-saved))))
+				   switch))
+		  (or (memq (gnus-data-mark (car data)) marks)
+		      (progn
+			(or
+			 (when (memq '?N marks)
+			   (memq (gnus-data-number (car data)) 
+				 gnus-newsgroup-new))
+			 (when (memq '?> marks)
+			   (memq (gnus-data-number (car data)) 
+				 gnus-newsgroup-downloaded))
+			 (when (memq '?# marks)
+			   (memq (gnus-data-number (car data)) 
+				 gnus-newsgroup-processable))
+			 (when (memq '?* marks)
+			   (memq (gnus-data-number (car data)) 
+				 gnus-newsgroup-cached))
+			 (when (memq '?A marks)
+			   (memq (gnus-data-number (car data)) 
+				 gnus-newsgroup-replied))
+			 (when (memq '?S marks)
+			   (memq (gnus-data-number (car data)) 
+				 gnus-newsgroup-saved))))))
 	    (push (gnus-data-number (car data)) articles))
 	  (setq data (cdr data)))
 	(gnus-summary-limit articles))
@@ -6998,34 +7112,41 @@
 		       (gnus-find-method-for-group to-newsgroup)))
 		  gnus-newsrc-hashtb)))
 	       (info (nth 2 entry))
-	       (to-group (gnus-info-group info)))
+	       (to-group (gnus-info-group info))
+	       (dont-copy-marks 
+		(gnus-group-get-parameter to-group 'dont-copy-marks)))
 	  ;; Update the group that has been moved to.
 	  (when (and info
 		     (memq action '(move copy)))
 	    (unless (member to-group to-groups)
 	      (push to-group to-groups))
-
-	    (unless (memq article gnus-newsgroup-unreads)
+	    
+	    (unless (or (memq article gnus-newsgroup-unreads) dont-copy-marks)
 	      (gnus-info-set-read
 	       info (gnus-add-to-range (gnus-info-read info)
 				       (list (cdr art-group)))))
 
 	    ;; Copy any marks over to the new group.
-	    (let ((marks gnus-article-mark-lists)
-		  (to-article (cdr art-group)))
-
-	      ;; See whether the article is to be put in the cache.
-	      (when gnus-use-cache
-		(gnus-cache-possibly-enter-article
-		 to-group to-article
-		 (let ((header (copy-sequence
-				(gnus-summary-article-header article))))
-		   (mail-header-set-number header to-article)
-		   header)
-		 (memq article gnus-newsgroup-marked)
-		 (memq article gnus-newsgroup-dormant)
-		 (memq article gnus-newsgroup-unreads)))
-
+	    (let ((marks (if dont-copy-marks '((new . new))
+			   gnus-article-mark-lists))
+		  (to-article (cdr art-group))
+		  (gnus-newsgroup-new 
+		   (if (or (memq article gnus-newsgroup-unreads)
+			   dont-copy-marks) (list article) nil)))
+	      
+	      (unless dont-copy-marks
+		;; See whether the article is to be put in the cache.
+		(when gnus-use-cache
+		  (gnus-cache-possibly-enter-article
+		   to-group to-article
+		   (let ((header (copy-sequence
+				  (gnus-summary-article-header article))))
+		     (mail-header-set-number header to-article)
+		     header)
+		   (memq article gnus-newsgroup-marked)
+		   (memq article gnus-newsgroup-dormant)
+		   (memq article gnus-newsgroup-unreads))))
+	      
 	      (when (and (equal to-group gnus-newsgroup-name)
 			 (not (memq article gnus-newsgroup-unreads)))
 		;; Mark this article as read in this group.
@@ -7078,8 +7199,12 @@
 	(set-buffer gnus-group-buffer)
 	(when (gnus-group-goto-group (car to-groups) t)
 	  (gnus-group-get-new-news-this-group 1 t))
+	(when gnus-mark-new-headers
+	  ;; Reset `last' regardless, in readiness for next time.
+	  (gnus-group-set-parameter (car to-groups) 'last
+				    (cdr (gnus-active (car to-groups)))))
 	(pop to-groups)))
-
+    
     (gnus-kill-buffer copy-buf)
     (gnus-summary-position-point)
     (gnus-set-mode-line 'summary)))
@@ -7153,7 +7278,7 @@
   (interactive "fImport file: ")
   (let ((group gnus-newsgroup-name)
 	(now (current-time))
-	atts lines)
+	atts lines group-art)
     (unless (gnus-check-backend-function 'request-accept-article group)
       (error "%s does not support article importing" group))
     (or (file-readable-p file)
@@ -7179,7 +7304,26 @@
 		"Message-ID: " (message-make-message-id) "\n"
 		"Lines: " (int-to-string lines) "\n"
 		"Chars: " (int-to-string (nth 7 atts)) "\n\n"))
-      (gnus-request-accept-article group nil t)
+      (setq group-art (gnus-request-accept-article group nil t))
+      (when gnus-mark-new-headers
+	(let* ((info (gnus-get-info group))
+	       (marks (gnus-info-marks info))
+	       (new (cdr (assq 'new marks))))
+	  (if new
+	      (setq new (gnus-add-to-range new (list (cdr group-art))))
+	    (setq new (list (cdr group-art))))
+	  (setq marks (delq (assq 'new marks) marks))
+	  (setq marks (append (list (cons 'new new)) marks))
+	  (gnus-info-set-marks info marks t))
+	(save-excursion
+	  (set-buffer gnus-group-buffer) 
+	  (gnus-group-update-group group)
+	  (save-excursion
+	    (gnus-group-goto-group group t)
+	    (gnus-group-get-new-news-this-group 1 t)))
+	;; `last' can now be made ready for next time.
+	(gnus-group-set-parameter group 'last
+				  (cdr (gnus-active group))))
       (kill-buffer (current-buffer)))))
 
 (defun gnus-summary-article-posted-p ()
@@ -7757,6 +7901,10 @@
 	  gnus-replied-mark)
 	 ((memq article gnus-newsgroup-saved)
 	  gnus-saved-mark)
+	 ((memq article gnus-newsgroup-new)
+	  gnus-new-mark)
+	 ((memq article gnus-newsgroup-downloaded)
+	  gnus-downloaded-mark)
 	 (t gnus-unread-mark))
    'replied)
   (when (gnus-visual-p 'summary-highlight 'highlight)
diff -ur gnus-orig/lisp/gnus.el gnus/lisp/gnus.el
--- gnus-orig/lisp/gnus.el	Sun Aug 16 17:59:46 1998
+++ gnus/lisp/gnus.el	Sun Aug 16 21:27:48 1998
@@ -1463,7 +1463,7 @@
     (bookmarks . bookmark) (dormant . dormant)
     (scored . score) (saved . save)
     (cached . cache) (downloadable . download)
-    (unsendable . unsend)))
+    (unsendable . unsend) (new . new) (downloaded . downloaded)))
 
 (defvar gnus-headers-retrieved-by nil)
 (defvar gnus-article-reply nil)
diff -ur gnus-orig/lisp/nnagent.el gnus/lisp/nnagent.el
--- gnus-orig/lisp/nnagent.el	Sat Jul 25 01:41:38 1998
+++ gnus/lisp/nnagent.el	Sun Aug 16 20:03:12 1998
@@ -110,7 +110,13 @@
 
 (deffoo nnagent-request-post (&optional server)
   (gnus-agent-insert-meta-information 'news gnus-command-method)
-  (gnus-request-accept-article "nndraft:queue"))
+  (gnus-request-accept-article "nndraft:queue")
+  (save-excursion
+    (set-buffer gnus-group-buffer) 
+    (gnus-group-update-group "nndraft:queue")
+    (save-excursion
+      (gnus-group-goto-group "nndraft:queue" t)
+      (gnus-group-get-new-news-this-group 1 t))))
 
 ;; Use nnml functions for just about everything.
 (nnoo-import nnagent
diff -ur gnus-orig/lisp/nnmail.el gnus/lisp/nnmail.el
--- gnus-orig/lisp/nnmail.el	Fri Aug 14 20:42:16 1998
+++ gnus/lisp/nnmail.el	Mon Aug 17 01:22:05 1998
@@ -1637,6 +1637,8 @@
 	 (nnmail-get-value "%s-active-file" method))
 	(when exit-func
 	  (funcall exit-func))
+	(when gnus-mark-new-headers
+	  (nnmail-update-new-marks))
 	(run-hooks 'nnmail-read-incoming-hook)
 	(nnheader-message 3 "%s: Reading incoming mail...done" method))
       ;; Close the message-id cache.
@@ -1650,6 +1652,29 @@
 	     (file-exists-p incoming)
 	     (file-writable-p incoming)
 	     (delete-file incoming))))))
+
+(defun nnmail-update-new-marks ()
+  "Update `new' marks in mail groups."
+  (let ((alist (nnmail-get-value "%s-group-alist" (car gnus-command-method))) 
+	group)
+    (while (setq group (pop alist))
+      (let*
+	  ((max (cdadr group))
+	   (group (gnus-group-prefixed-name (car group) gnus-command-method)) 
+	   (info (gnus-get-info group))
+	   (marks (gnus-info-marks info))
+	   (last (gnus-group-get-parameter group 'last))
+	   new-arts new)
+	(when (and max last)
+	  (if (> max last)
+	      (progn
+		(setq new-arts (cons (1+ last) max))
+		(setq new (gnus-range-add (cdr (assq 'new marks))
+					  new-arts))
+		(setq marks (delq (assq 'new marks) marks))
+		(setq marks (append (list (cons 'new new)) marks))
+		(gnus-info-set-marks info marks t)
+		(gnus-group-set-parameter group 'last max))))))))
 
 (defun nnmail-expired-article-p (group time force &optional inhibit)
   "Say whether an article that is TIME old in GROUP should be expired."

Suggestion: Command to rename all Subejcts in thread

[Jari Aalto+list.ding]

    Hi,

    As email is the primary communication channel to customers, our
    support persons and to lab people, it's very usual that people send
    Subjects that don't tell much. Eg:

        Subject: Process won't stay up
    
    Then several people take into part the discussion, but the subject
    stays the same.

    I would like to see a command in Summary buffer where I could
    stand at the top of thread and appply

        "Change ann messages' Subject in this theread to...."

    So that I can write something that better describes the problem
    beeing discussed, like adding system version, customer code, 
    process name etc.

    It also happens that I move several messages under one thread, because
    they are talking about the same thing, so the Subject rename command
    would be of assis here too. No I see different subjects under
    same thread where I have moved them.

    Pretty, Please Lars, Any chance to see that command in near future?

    jari

Re: request: commands for subsribe/unsubsribe from/to mailing lists

[Christopher Davis]

WMP> == William M Perry <wmperry@aventail.com>

 WMP> how absolutely #!%@!ing worthless.  I really yearn for the good
 WMP> old days.  I remember when chris wilson and I were floored in July
 WMP> '94 by the fact that some airplane flying around seattle's big
 WMP> fourth of july pary area had a URL on it.  We laughed that nobody
 WMP> would know what it was...

I walked to work this morning past a construction site.  They had one of
those portable chemical toilets (you know, plastic, looks sort of like a
really cheap TARDIS) next to the gate.

The sign on the side of the toilet gave the name of the company it was
rented from, their 800 number, AND THEIR URL.  I kid you not.

Naturally I visited their web site <URL:http://www.handyhouse.com/>.
They provided service for Pope John Paul II's visit to New England!
They have a FAQ!  They have pictures of their product line!  We're
doomed, doomed I say.

(Obding: so, maybe that's an idea for the next Gnus promotional item?)

Re: Suggestion: Command to rename all Subejcts in thread

[Lars Magne Ingebrigtsen]

<jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

> I would like to see a command in Summary buffer where I could
> stand at the top of thread and appply
> 
> "Change ann messages' Subject in this theread to...."

[...]

> Pretty, Please Lars, Any chance to see that command in near future?

I don't think this would be very useful, so I'm not going to write
it.  I'll apply the patches if someone does, though.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Suggestion: Command to rename all Subejcts in thread

[Jari Aalto+list.ding]

| 1998-08-20 Lars Magne Ingebrigtsen <larsi@gnus.org> list.ding
| > 
| > "Change ann messages' Subject in this theread to...."
| 
| I don't think this would be very useful, so I'm not going to write
| it.  I'll apply the patches if someone does, though.

I would desperately need it, so I could try wtiting the code, would
you tell me how:

   - I go to the top of a thread (to get beginning point)
   - I get all message numbers of the thread below the current article.

jari
   

Re: Suggestion: Command to rename all Subejcts in thread

[Lars Magne Ingebrigtsen]

<jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

> I would desperately need it, so I could try wtiting the code, would
> you tell me how:
> 
>    - I go to the top of a thread (to get beginning point)

`gnus-summary-top-thread'

>    - I get all message numbers of the thread below the current article.

`gnus-uu-mark-thread' and then `gnus-summary-work-articles'.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

5.6.38 Can't read drafts server?

[Jari Aalto+list.ding]

    Gnus denies access to drafts grou when I press SPC.
    What should I check?

    jari

Group buffer:

       [1]     0      *: nndraft:queue      0 
       [1]     0      *: nndraft:drafts     0 

Messages when pressing SPC:

    nndraft:queue error: Opened server  
    using directory /users/jaalto/News/drafts/

    nndraft:drafts error: Opened server  
    using directory /users/jaalto/News/drafts/

Directory:

creator gnus ls -la /users/jaalto/News/drafts/
total 10
drwxr-xr-x   4 jaalto     nms             96 May  7 15:27 .
drwxr-xr-x   6 jaalto     nms           4096 May 26 19:10 ..
drwxr-xr-x   2 jaalto     nms           1024 Aug 20 23:26 drafts
drwxr-xr-x   2 jaalto     nms             96 May  7 15:27 queue

creator gnus ls -la /users/jaalto/News/drafts/drafts/
total 134
-rw-r--r--   1 jaalto     nms           9083 Aug 19 21:03 #68#
-rw-r--r--   1 jaalto     nms            727 Aug 20 23:28 #87#
drwxr-xr-x   2 jaalto     nms           1024 Aug 20 23:26 .
drwxr-xr-x   4 jaalto     nms             96 May  7 15:27 ..
-rw-r--r--   1 jaalto     nms            964 May  7 15:27 10~
-rw-r--r--   1 jaalto     nms          14507 Jun 23 15:05 50
-rw-r--r--   1 jaalto     nms          11171 Jun 24 16:29 52
-rw-r--r--   1 jaalto     nms          10793 Jun 24 16:29 53
-rw-r--r--   1 jaalto     nms           9077 Aug 19 21:04 68
-rw-r--r--   1 jaalto     nms           7597 Aug 19 22:22 77
-rw-r--r--   1 jaalto     nms             71 Aug 20 23:16 86

creator gnus ls -la /users/jaalto/News/drafts/queue/
total 0
drwxr-xr-x   2 jaalto     nms             96 May  7 15:27 .
drwxr-xr-x   4 jaalto     nms             96 May  7 15:27 ..

Re: 5.6.38 Can't read drafts server?

[Lars Magne Ingebrigtsen]

<jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

> Gnus denies access to drafts grou when I press SPC.
> What should I check?

When did this start happening?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Marking new unread articles differently?

[Lars Magne Ingebrigtsen]

Mike McEwan <mike@lotusland.demon.co.uk> writes:

>   I've probably gone a little wild here. You know how it is - start
> with a little function here, a tweak there :-). My functions aren't
> prefixed with `my-gnus..' either, but there just weren't enough
> hooks! Please note I haven't really used this with offline news
> reading, it's still a little rough I think. I'd appreciate hearing
> what folks think. I'll provide some more doc if folks are
> confused.Lars d'you think we (the off-liners anyway) could have
> something like this?

Looks OK to me, but I'll be holding off on this stuff until pgnus. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: 5.6.38 Can't read drafts server?

[Jari Aalto+list.ding]

| 1998-08-20 Lars Magne Ingebrigtsen <larsi@gnus.org> list.ding
| <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:
| 
| > Gnus denies access to drafts grou when I press SPC.
| > What should I check?
| 
| When did this start happening?

I have no idea. I haven't accesd the dtaft group for ages, but
recently our newserver had reported "no space left on device" so
I saved unposted articles with C-x C-s.

Next day (when I reported the problem) I tried to access draft group
and was suprised that I could get inside.

Is there some function you want me to edebug?

jari

pop3 reading with gnus?

[jari.aalto]

    Hi,

    Does anyone have pointers to set up Gnus for POP3 mailboxes
    in remoe sites?

    jari

Re: pop3 reading with gnus?

[Jean-Yves Perrier]

<jari.aalto@poboxes.com> writes:

>     Hi,
> 
>     Does anyone have pointers to set up Gnus for POP3 mailboxes
>     in remoe sites?
> 
>     jari

This is what I have in .gnus:

;; Needed for sending mail (message-mode): use SMTP
(load-library "message")
(setq message-send-mail-function 'smtpmail-send-it)
(require 'messcompat)

;; Read mail from popserver
(setenv "MAILHOST" "mailhost.mycompany.ch") ;; my remote pop mail serveur: configure it....
(setq nnmail-spool-file "po:perrier") ;; my account po:<username>
(setq nnmail-movemail-program 'nnmail-pop3-movemail)

;; Use gnus to read mail, too
(setq gnus-secondary-select-methods
           '((nnml "")))

More info can be found in the gnus FAQ and nt-emacs FAQ.

Regards,

-- 
Jean-Yves Perrier

Re: pop3 reading with gnus?

[Jari Aalto+list.ding]

| 1998-08-21 Jean-Yves Perrier <perrier@nagra-kudelski.ch> list.ding
| <jari.aalto@poboxes.com> writes:
| 
| >     Hi,
| > 
| >     Does anyone have pointers to set up Gnus for POP3 mailboxes
| >     in remoe sites?
| > 
| >     jari
| 
| This is what I have in .gnus:
| 
| ;; Needed for sending mail (message-mode): use SMTP
| (load-library "message")
| (setq message-send-mail-function 'smtpmail-send-it)
| (require 'messcompat)
| 
| ;; Read mail from popserver
| (setenv "MAILHOST" "mailhost.mycompany.ch") ;; my remote pop mail serveur: configure it....
| (setq nnmail-spool-file "po:perrier") ;; my account po:<username>
| (setq nnmail-movemail-program 'nnmail-pop3-movemail)
| 
| ;; Use gnus to read mail, too
| (setq gnus-secondary-select-methods
|            '((nnml "")))


Thank you, but I assume this is for one POP3 mailbox reading only. I 
have 2 remote pop3 mailboxes in different servers and one local mailbox
where I'm 99% of the time. so I'd like to add those remote fileboxes
behind a gnus pop3 server, but I'm not quite sure how it is done.
My first impression after looking at the pop3 varaibles in the manual
was that I create nnml 

    server:tpu

Which has entries

    (nnml "tpu"
          (nnmail-pop-password "cencored")
          (nnmail-pop-password-required t)
          (pop3-mailhost "mail.cs.tpu.fi")
          (nnmail-spool-file "po:jaalto"))

Then I created Gnus group nnml "tpu" by using that server, but
somehow the movemail program want to look under local disk 'po:jaalto'

What's the correct way to define multiple pop3 servers and use them?
My primary local mail delivery method is procmail 

       nnmail-use-procmail        t
       nnmail-procmail-directory  (concat nnfolder-directory  "/spool")
       nnmail-spool-file          'procmail

        gnus-secondary-select-methods's value is ((nnml ""))
        gnus-secondary-servers's value is nil

jari

Re: 5.6.38 Can't read drafts server?

[Karl Kleinpaste]

<jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:
>> Gnus denies access to drafts grou when I press SPC.

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> When did this start happening?

Drafts have been working fine for me in both .37 and .38.

Suggestion: *Group* SPC to show only new articles?

[Jari Aalto+list.ding]

    Would it be possible to add eg. new symbolic prefix argument
    to SPC key that is used to enter a group (I'm using topic mode)

        gnus-topic-read-group
        
    So that gnus would show only newly arrived articles. Now I manually
    Hit the count of the arrived articles to see what's new in there:
    Eg. if 2 messages has arrived, I can browse the group lighting fast
    with:

        M-2 gnus-topic-read-group
        
    But it's pain to enter different number for each group. 

    jari
        

Re: Marking new unread articles differently?

[Mike McEwan]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Looks OK to me, but I'll be holding off on this stuff until pgnus. 

  Great. Would it be OK if I re-mail my patches when we're into the
pgnus cycle - I'm still tweaking?

-- 
Mike.

Re: 5.6.38 Can't read drafts server?

[Lars Magne Ingebrigtsen]

<jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

> Next day (when I reported the problem) I tried to access draft group
> and was suprised that I could get inside.
> 
> Is there some function you want me to edebug?

nnmh-request-group, for instance.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: pop3 reading with gnus?

[Lars Magne Ingebrigtsen]

<jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

> What's the correct way to define multiple pop3 servers and use them?

There is no pre-defined functionality in Gnus for doing this.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Suggestion: *Group* SPC to show only new articles?

[Lars Magne Ingebrigtsen]

<jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

> Now I manually
> Hit the count of the arrived articles to see what's new in there:
> Eg. if 2 messages has arrived, I can browse the group lighting fast
> with:
> 
> M-2 gnus-topic-read-group
> 
> But it's pain to enter different number for each group. 

I'd suggest writing a function do to this.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Marking new unread articles differently?

[Lars Magne Ingebrigtsen]

Mike McEwan <mike@lotusland.demon.co.uk> writes:

> > Looks OK to me, but I'll be holding off on this stuff until pgnus. 
> 
>   Great. Would it be OK if I re-mail my patches when we're into the
> pgnus cycle - I'm still tweaking?

Yes; I'd prefer that, in fact.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: pop3 reading with gnus?

[William M. Perry]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:
> 
> > What's the correct way to define multiple pop3 servers and use them?
> 
> There is no pre-defined functionality in Gnus for doing this.

  I use VM's pop support to do this.  Try:

(defun my-movemail (inbox crashbox)
  (require 'vm)
  (vm-spool-move-mail (getenv "MAIL") crashbox)
  (vm-pop-move-mail "milo.in.aventail.com:110:pass:wmperry:YYYYYYYY" crashbox)
  (vm-pop-move-mail "mail.cntwk.net:110:pass:wmperry:YYYYYYYY" crashbox)
  (vm-pop-move-mail "moose.cs.indiana.edu:110:pass:wmperry:ZZZZZZZZZZZ" crashbox))

(setq nnmail-movemail-program 'my-movemail)

-Bill P.

patch: 5.6.38 gnus-uu, new regexp marking commands

[Jari Aalto+list.ding]

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


    Hi,

    A day ago I subscribed to handfull of new mailing lists and when I
    was away last night my procmail recipes sorted them to wrong folders.
    so I had to move lot of mail from group to another.

    The first command that come into my mind was 

	gnus-uu-mark-by-regexp

    But it only matched subjects. I assumed it would match the 
    visible Summary line, but it didn't :-). There was nothing in common
    in the subject lines that come from eg liserv XXX. However If I
    matched against From field, then I could tag all the messages
    coming from particular list and move then all to right group.

    Here is the new functions that do that: They un/mark articles
    that match From field. The patch is against 5.6.38. Feel free
    to move the new keybinds to somewhere more appropriate.

    jari



[-- Attachment #2: Type: text/plain, Size: 639 bytes --]

Sat Aug 22 17:56:04 1998  Jari Aalto  <jari.aalto@poboxes.com>

	* gnus-uu.el ((gnus-uu-mark-map "P" gnus-summary-mark-map)):
	Added commands
	"f" gnus-uu-mark-by-from-regexp
	"F" gnus-uu-unmark-by-from-regexp
	(gnus-uu-mark-by-from-regexp): New user function.
	(gnus-uu-find-articles-matching): Added anew arg `data-flag'
	Which may have other uses in the future. Curretly if flag
	is set to non-nil, the matching list is generated by looking
	at `from' fields. If flag is nil, then list is generated
	by looking at `subject'.
	(gnus-uu-find-articles-matching): variable changes
	`list-of-subjects' --> `list' and `subject' --> `string'


[-- Attachment #3: gnus-uu.el.diff --]
[-- Type: text/plain, Size: 3108 bytes --]

Prereq: 1.1

===================================================================
RCS file: RCS/gnus-uu.el,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- 1.1	1998/08/22 14:53:26
+++ 1.2	1998/08/22 15:01:27
@@ -356,6 +356,8 @@
   "g" gnus-uu-unmark-region
   "R" gnus-uu-mark-by-regexp
   "G" gnus-uu-unmark-by-regexp
+  "f" gnus-uu-mark-by-from-regexp
+  "F" gnus-uu-unmark-by-from-regexp
   "t" gnus-uu-mark-thread
   "T" gnus-uu-unmark-thread
   "a" gnus-uu-mark-all
@@ -578,6 +580,25 @@
   (interactive (list (read-from-minibuffer "Mark (regexp): ")))
   (gnus-uu-mark-by-regexp regexp t))
 
+
+(defun gnus-uu-mark-by-from-regexp (regexp &optional unmark)
+  "Ask for a regular expression and set the process mark on all articles that match `From'."
+  (interactive (list (read-from-minibuffer "Mark (From regexp): ")))
+  (let ((articles (gnus-uu-find-articles-matching regexp nil nil 'from)))
+    (while articles
+      (if unmark
+	  (gnus-summary-remove-process-mark (pop articles))
+	(gnus-summary-set-process-mark (pop articles))))
+    (message ""))
+  (gnus-summary-position-point))
+
+
+(defun gnus-uu-unmark-by-from-regexp (regexp &optional unmark)
+  "Ask for a regular expression and remove the process mark on all articles that match `from' ."
+  (interactive (list (read-from-minibuffer "Mark (regexp): ")))
+  (gnus-uu-mark-by-from-regexp regexp t))
+
+
 (defun gnus-uu-mark-series ()
   "Mark the current series with the process mark."
   (interactive)
@@ -1081,14 +1102,19 @@
   (string< (car l1) (car l2)))
 
 (defun gnus-uu-find-articles-matching
-  (&optional subject only-unread do-not-translate)
+  (&optional subject only-unread do-not-translate data-flag)
   ;; Finds all articles that matches the regexp SUBJECT.  If it is
   ;; nil, the current article name will be used.  If ONLY-UNREAD is
   ;; non-nil, only unread articles are chosen.  If DO-NOT-TRANSLATE is
   ;; non-nil, article names are not equalized before sorting.
+  ;;
+  ;; If DATA-FLAG is non-nil, match `from' gnus-data instead of `subject'
   (let ((subject (or subject
 		     (gnus-uu-reginize-string (gnus-summary-article-subject))))
-	list-of-subjects)
+	list
+	from
+	string
+	)
     (save-excursion
       (if (not subject)
 	  ()
@@ -1104,16 +1130,21 @@
 			gnus-unread-mark)
 		     (= mark gnus-ticked-mark)
 		     (= mark gnus-dormant-mark))
-		 (setq subj (mail-header-subject (gnus-data-header d)))
-		 (string-match subject subj)
-		 (push (cons subj (gnus-data-number d))
-		       list-of-subjects))))
+		 (cond
+		  ((null data-flag)
+		   (setq string (mail-header-subject (gnus-data-header d)))
+		   (string-match subject string))
+		  (t
+		   (setq string (mail-header-from (gnus-data-header d)))
+		   (string-match subject string)))
+		 (push (cons string (gnus-data-number d))
+		       list))))
 
 	;; Expand numbers, sort, and return the list of article
 	;; numbers.
 	(mapcar (lambda (sub) (cdr sub))
 		(sort (gnus-uu-expand-numbers
-		       list-of-subjects
+		       list
 		       (not do-not-translate))
 		      'gnus-uu-string<))))))
 


    
    

Re: patch: 5.6.38 gnus-uu, new regexp marking commands

[Lars Magne Ingebrigtsen]

<jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

>     Here is the new functions that do that: They un/mark articles
>     that match From field.

I don't think adding more specialized functions for setting the
process mark on other headers is a good idea.  The limiting commands
already allow you to limit on an arbitrary header, which is what
should be used instead.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: 5.6.38 Can't read drafts server?

[Jari Aalto+list.ding]

| 1998-08-21 Lars Magne Ingebrigtsen <larsi@gnus.org> list.ding
| <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:
| 
| > Next day (when I reported the problem) I tried to access draft group
| > and was suprised that I could get inside.
| > 
| > Is there some function you want me to edebug?
| 
| nnmh-request-group, for instance.

I didn't reach that far, I was able to go to point
gnus-request-group, but then it called function 
nndraft-request-group which I couldn't find anywhere to instrument
it for Edebug.

How do I continue tracing?
jari



(defun gnus-activate-group (group &optional scan dont-check method)
  ;; Check whether a group has been activated or not.
  ;; If SCAN, request a scan of that group as well.
  (let ((method (or method (inline (gnus-find-method-for-group group))))
        active)
    (and (inline (gnus-check-server method))
         ;; We escape all bugs and quit here to make it possible to
         ;; continue if a group is so out-there that it reports bugs
         ;; and stuff.
         (progn
           (and scan
                (gnus-check-backend-function 'request-scan (car method))
                (gnus-request-scan group method))
           t)
         (condition-case ()
==>          (inline (gnus-request-group group dont-check method))
           (error nil)
           (quit nil))
         (setq active (gnus-parse-active))



(defun gnus-request-group (group &optional dont-check gnus-command-method)
  "Request GROUP.  If DONT-CHECK, no information is required."
  (let ((gnus-command-method
         (or gnus-command-method (inline (gnus-find-method-for-group group)))))
    (when (stringp gnus-command-method)
      (setq gnus-command-method
            (inline (gnus-server-to-method gnus-command-method))))

--> nndraft-request-group

    (funcall (inline (gnus-get-function gnus-command-method 'request-group))
             (gnus-group-real-name group) (nth 1 gnus-command-method)
             dont-check)))

Re: Suggestion: *Group* SPC to show only new articles?

[Kai Grossjohann]

>>>>> <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

  >     Eg. if 2 messages has arrived, I can browse the group lighting fast
  >     with:
  > 
  >         M-2 gnus-topic-read-group

Doesn't just SPC do this?  It might fetch a bit more if
gnus-fetch-old-headers is non-nil, but you can easily fix that.

kai
-- 
OOP: object oriented programming;  OOPS: object oriented mistakes

Re: Suggestion: *Group* SPC to show only new articles?

[Jari Aalto+list.ding]

| 1998-08-24 Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> list.ding
|
|   >         M-2 gnus-topic-read-group [fast way to access group]
| 
| Doesn't just SPC do this?  It might fetch a bit more if
| gnus-fetch-old-headers is non-nil, but you can easily fix that.

Exellent suggestion, but SPC also shows ticked articles. I would
like to see only new articles when I enter a group. It seems that
giving a number still doesn't give /only/ the new articles.

Would anyone have more suggestions? I'd love to see Prefix or
function to show only arrived articles.

jari

Re: Suggestion: *Group* SPC to show only new articles?

[Kai Grossjohann]

>>>>> <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

  > Exellent suggestion, but SPC also shows ticked articles. I would
  > like to see only new articles when I enter a group. It seems that
  > giving a number still doesn't give /only/ the new articles.

Hm.  Well, ticked articles are made so that they are always shown.
Dormant articles are similar to ticked ones, except that they're only
shown when there is a followup or an explicit request from the user.

You might want to use `/ m SPC RET' to only show the unmarked messages
after entering a group.  It should be simple to write a function which
uses RET or SPC to enter a group then the above command to unshow the
ticked articles.

kai
-- 
OOP: object oriented programming;  OOPS: object oriented mistakes

Re: Suggestion: *Group* SPC to show only new articles?

[Jari Aalto+list.ding]

| 1998-08-24 Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> list.ding
| >>>>> <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:
| 
|   > like to see only new articles when I enter a group. It seems that
|   > giving a number still doesn't give /only/ the new articles.
| 
| Hm.  Well, ticked articles are made so that they are always shown.
| You might want to use `/ m SPC RET' to only show the unmarked messages
| after entering a group.  It should be simple to write a function which
| uses RET or SPC to enter a group then the above command to unshow the
| ticked articles.

All that of course works, but I would like to avoid the phase or
Creating Large Summary buffer altogether. I'm looking for speed here.
Many of my groups have 10's of ticked (in work groups, hundreads) 
articles and this mean lot of extra work for Gnus, and it slows
down Getting the Summary displayed. Limiting is another step still.

Gnus must know which articles are new, so building summary based on
them only should be trivial. And when combined with

    (gnus-fetch-old-headers nil)

that'd be the fast access to new articles.
What gnus functions variables is needed here?

jari

Re: Suggestion: *Group* SPC to show only new articles?

[Kai Grossjohann]

>>>>> <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

  > Gnus must know which articles are new, so building summary based on
  > them only should be trivial. And when combined with
  > 
  >     (gnus-fetch-old-headers nil)
  > 
  > that'd be the fast access to new articles.
  > What gnus functions variables is needed here?

Well, in recent Gnusae, you can give a parameter to the internal group
reading function which gives the list of articles to display.  See
nnir.el for an example.  And I think there's a variable or function
which gives you the unread messages.

kai
-- 
OOP: object oriented programming;  OOPS: object oriented mistakes

Re: Suggestion: *Group* SPC to show only new articles?

[Francisco Solsona]

Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> writes:

> >>>>> <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:
> 
>   > Gnus must know which articles are new, so building summary based on
>   > them only should be trivial. And when combined with
>   > 
>   >     (gnus-fetch-old-headers nil)
>   > 
>   > that'd be the fast access to new articles.
>   > What gnus functions variables is needed here?
> 
> Well, in recent Gnusae, you can give a parameter to the internal group
> reading function which gives the list of articles to display.  See
> nnir.el for an example.  And I think there's a variable or function
> which gives you the unread messages.

	Actually, seeing only the unread articles seems a very useful
functionality. What about binding something like this:

(defun my-gnus-topic-read-group ()
  (interactive)
  (gnus-topic-read-group (gnus-group-group-unread)))

to SPC in the *group* buff ?, this --I believe-- should be the fastest
way of doing it.

Francisco
-- 
Real computer scientists like having a computer on their desk, else how
could they read their mail?

Re: Suggestion: *Group* SPC to show only new articles?

[Mike McEwan]

<jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

> Gnus must know which articles are new, so building summary based on
> them only should be trivial. And when combined with
> 
>     (gnus-fetch-old-headers nil)
> 
> that'd be the fast access to new articles.
> What gnus functions variables is needed here?

  Well, maybe you didn't see my followup mailing to yours in an earlier 
thread "Marking new unread articles differently?", or maybe you did,
but didn't like what you saw :-). 

  Gnus does *not* know which headers/articles are `new' (here I am
taking `new' to mean headers/articles that have arrived since the last 
time a given group was selected). It only knows which articles are
`unread'. This may suffice for folks that mark everything as `read'
each time they select a group, but this is not the case with me,
particularly where large groups are concerned.

  In order to ascertain what is genuinely `new' since a group was last
selected, you have to have some mechanism of knowing what the last
header/article retrieved for a group was. `new' headers/articles
*only* can then be selected via use of the SELECT-ARTICLES argument to 
`gnus-group-read-group'. Just selecting a number of `new'
headers/articles does not always do it where real newsgroups are
concerned as some articles may have been cancelled and you get `old'
non-new articles in their place.

  I'm still tweaking with the patch I mailed on the above-mentioned
thread, but generally everything works just fine. Lars has said he
will not consider such new function until we're into the `pgnus'
cycle, at which time I'll re-mail what I have to this group. In the
meantime I'm using CVS to re-merge my patch with each release of
gnus (I like that CVS), there aren't enough hooks to keep the code
isolated.

  If you really did miss my previous mailing, and want, I'll mail my
current patch to you. If not, and you don't, I'll understand :-).

-- 
Mike.

Suggestion: Topic mode get news and topic group indentation level

[Jari Aalto+list.ding]

    I know that topics don't actually "nest", but would it be possible.
    I would find it neat to Hit M-g at topmost topic level 
    and get all subtopics read in.

        Main-Topic          <-- Hit M-g and get Topic1, Topic2 read?
            Sub-Topic1
            Sub-Topic2

    I guess that would be matter of looping through topics
    that have indentation level ++ compared to current topic 
    indentation level.

    jari

Re: 5.6.38 Can't read drafts server?

[Lars Magne Ingebrigtsen]

<jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

> | nnmh-request-group, for instance.
> 
> I didn't reach that far, I was able to go to point
> gnus-request-group, but then it called function 
> nndraft-request-group which I couldn't find anywhere to instrument
> it for Edebug.

`nnmh-request-group' is the function to instrument.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Suggestion: Topic mode get news and topic group indentation level

[Lars Magne Ingebrigtsen]

<jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

> I would find it neat to Hit M-g at topmost topic level and get all
> subtopics read in.

Well, I considered doing it that way, but I decided against it for
some reason.  And I don't want to change it now.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Marking new unread articles differently?

[Matt Simmons]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    Matt> I can't be the only one who has obscene numbers of unread messages
    Matt> rotting away in my mailbox.  This causes me to lose new messages,
    Matt> especially when the appear as part of a thread headed by previously
    Matt> unread messages.

    Lars> Well -- don't you want to read messages earlier in the thread before
    Lars> messages later in the thread?

I do.  I just want the messages that have appeared since the last inc
to show up in a way that calls attention to them (a different face,
preferably, but a mark would do in a pinch).  When you have large
numbers of unread messages, it's difficult to find the one new one
that just added itself to a thread.

    Matt> Is there any way to have the messages that have appeared since the
    Matt> last time the spool was inc'd displayed in a different face in the
    Matt> Summary Buffer?  This would make it easier to differentiate between
    Matt> old and new unread messages.

    Lars> I think it sounds like you really want an unthreaded mail group
    Lars> summary display.

No..  I need the threaded display.  I'd like to be able to find, at a
glance, the stealth replies that have attached themselves to old
threads.

Matt

-- 
     Matt Simmons  -  simmonmt@acm.org  -  http://www.netcom.com/~simmonmt
	  The more times you run over a dead cat, the flatter it gets.

Re: Marking new unread articles differently?

[Matt Simmons]

>>>>> "Mike" == Mike McEwan <mike@lotusland.demon.co.uk> writes:

    Lars> Looks OK to me, but I'll be holding off on this stuff until pgnus. 

    Mike> Great. Would it be OK if I re-mail my patches when we're into the
    Mike> pgnus cycle - I'm still tweaking?

Would it be difficult to tweak it such that a different face was used
for the new messages?  It's much easier to spot a message when it's
entire line is distinctive.

Thanks

Matt

-- 
     Matt Simmons  -  simmonmt@acm.org  -  http://www.netcom.com/~simmonmt
      The world is full of willing people; some willing to work, the rest
                      willing to let them.  --Robert Frost

Re: 5.6.38 Can't read drafts server?

[Jari Aalto+list.ding]

| 1998-08-25 Lars Magne Ingebrigtsen <larsi@gnus.org> list.ding
| <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:
| 
| > | nnmh-request-group, for instance.
| > 
| > I didn't reach that far, I was able to go to point
| > gnus-request-group, but then it called function 
| > nndraft-request-group which I couldn't find anywhere to instrument
| > it for Edebug.
| 
| `nnmh-request-group' is the function to instrument.

I did that, but It never stops there...When I
instrumented the nnmh-request-group' it said:

    Mark saved where search started [2 times]
    Edebug: edebug-anon0
    Edebug: nnmh-request-group

I'm currently stuck at this point:

(defun gnus-request-group (group &optional dont-check gnus-command-method)
  "Request GROUP.  If DONT-CHECK, no information is required."
  (let ((gnus-command-method
         (or gnus-command-method (inline (gnus-find-method-for-group group)))))
    (when (stringp gnus-command-method)
      (setq gnus-command-method
            (inline (gnus-server-to-method gnus-command-method))))
=>    (funcall (inline (gnus-get-function gnus-command-method 'request-group))
             (gnus-group-real-name group) (nth 1 gnus-command-method)
             dont-check)))


    (gnus-get-function gnus-command-method (quote request-group))
    --> nndraft-request-group


The "i" is hopeless here, since I get

      Signaling: (error "Don't know where gnus-get-function is defined")
      apply(debug error(error "Don't know where gnus-get-function is defined"))
      edebug(error (error "Don't know where gnus-get-function is defined"))
      signal(error ("Don't know where gnus-get-function is defined"))

The call seems to be:

    (nndraft-request-group "drafts" "" nil)

And I  called it directly to find out it it would trigger edebug
and nnmh-request-group...no joy.

How do I get past and land to nnmh-request-group?
jari

Re: Marking new unread articles differently?

[Mike McEwan]

Matt Simmons <simmonmt@acm.org> writes:

> Would it be difficult to tweak it such that a different face was used
> for the new messages?  It's much easier to spot a message when it's
> entire line is distinctive.

 Well, it was a little tricky, but I think I've got it sussed. It's
 so damned hard picking what colours to have :-).

 If you'd like me to mail you what I've got so far, drop me a note. My
 current patch is against gnus-5.6.39. You probably need something
 like CVS if you like to update your gnusae (is that the right word?)
 as fast as Lars throws them at you and wish to re-apply local
 updates.

-- 
Mike.

Hallvard's gnus-e20/19.34/Pgnus 0.13 emulation (backtrace included)

[Jari Aalto+list.ding]

    
    I'm having great success running Pgnus with 19.34, but then I hit this.
    (Thanks Hallvard's for gnus-e20.el)

        (gnus-version)"Pterodactyl Gnus v0.13

    Does string-to-number take new parameter in Emacs 20.x ? Anyone
    care to post the emulation function?

    jari

qp.el

(defun quoted-printable-decode-region (from to)
  "Decode quoted-printable in the region between FROM and TO."
  (interactive "r")
  (save-excursion
    (goto-char from)
    (while (search-forward "=" to t)
      (cond ((eq (following-char) ?\n)
             (delete-char -1)
             (delete-char 1))
            ((and
              (memq (following-char) quoted-printable-encoding-characters)
              (memq (char-after (1+ (point)))
                    quoted-printable-encoding-characters))
             (subst-char-in-region
              (1- (point)) (point) ?=
              (string-to-number
               (buffer-substring (point) (+ 2 (point)))
>>             16))
             (delete-char 2))
            ((looking-at "=")
             (delete-char 1))
            ((message "Malformed MIME quoted-printable message"))))))



Signaling: (wrong-number-of-arguments #<subr string-to-number> 2)
  (string-to-number (buffer-substring (point) (+ 2 ...)) 16)
  (subst-char-in-region (1- (point)) (point) 61 (string-to-number (buffer-substring ... ...) 16))
  (cond ((eq ... 10) (delete-char -1) (delete-char 1)) ((and ... ...) (subst-char-in-region ... ... 61 ...) (delete-char 2)) ((looking-at "=") (delete-char 1)) ((message "Malformed MIME quoted-printable message")))
  (while (search-forward "=" to t) (cond (... ... ...) (... ... ...) (... ...) (...)))
  (save-excursion (goto-char from) (while (search-forward "=" to t) (cond ... ... ... ...)))
  quoted-printable-decode-region(2316 2573)
  (progn (goto-char (point-min)) (search-forward "\n\n" nil (quote move)) (quoted-printable-decode-region (point) (point-max)))
  (if (or force (and type ...)) (progn (goto-char ...) (search-forward "\n\n" nil ...) (quoted-printable-decode-region ... ...)))
  (when (or force (and type ...)) (goto-char (point-min)) (search-forward "\n\n" nil (quote move)) (quoted-printable-decode-region (point) (point-max)))
  (let ((buffer-read-only nil) (type ...)) (gnus-article-decode-rfc1522) (when (or force ...) (goto-char ...) (search-forward "\n\n" nil ...) (quoted-printable-decode-region ... ...)))
  (save-excursion (let (... ...) (gnus-article-decode-rfc1522) (when ... ... ... ...)))
  article-de-quoted-unreadable()
  apply(article-de-quoted-unreadable nil)
  (if interactive (call-interactively (quote article-de-quoted-unreadable)) (apply (quote article-de-quoted-unreadable) args))
  (save-excursion (set-buffer gnus-article-buffer) (if interactive (call-interactively ...) (apply ... args)))
  gnus-article-de-quoted-unreadable()
  (progn (when (boundp ...) (cond ... ...)) (gnus-article-de-quoted-unreadable) (if (fboundp ...) (gnus-article-strip-multiple-blank-lines)) (gnus-article-hide-citation-maybe nil) (gnus-article-hide-signature nil) (when (string-match "nntp" gnus-newsgroup-name) (gnus-article-hide-headers nil)) (when (re-search-check "PGP ") (if ... ... ...)) (my-gnus-article-url) (when (fboundp ...) (gnus-article-date-user)) (when my-:window-system) (when (string-match "XEmacs" emacs-version)) (when (fboundp ...)) (when (and ... ...) (let ... ...)))
  (if (buffer-live-p (get-buffer gnus-article-buffer)) (progn (when ... ...) (gnus-article-de-quoted-unreadable) (if ... ...) (gnus-article-hide-citation-maybe nil) (gnus-article-hide-signature nil) (when ... ...) (when ... ...) (my-gnus-article-url) (when ... ...) (when my-:window-system) (when ...) (when ...) (when ... ...)))
  (when (buffer-live-p (get-buffer gnus-article-buffer)) (when (boundp ...) (cond ... ...)) (gnus-article-de-quoted-unreadable) (if (fboundp ...) (gnus-article-strip-multiple-blank-lines)) (gnus-article-hide-citation-maybe nil) (gnus-article-hide-signature nil) (when (string-match "nntp" gnus-newsgroup-name) (gnus-article-hide-headers nil)) (when (re-search-check "PGP ") (if ... ... ...)) (my-gnus-article-url) (when (fboundp ...) (gnus-article-date-user)) (when my-:window-system) (when (string-match "XEmacs" emacs-version)) (when (fboundp ...)) (when (and ... ...) (let ... ...)))
  my-gnus-article-display-hook-list()
  run-hooks(gnus-article-display-hook)
  apply(run-hooks gnus-article-display-hook)
  (unwind-protect (apply (quote run-hooks) funcs) (set-buffer buf))
  (let ((buf ...)) (unwind-protect (apply ... funcs) (set-buffer buf)))
  gnus-run-hooks(gnus-article-display-hook)
  (let (buffer-read-only) (gnus-run-hooks (quote gnus-tmp-internal-hook)) (gnus-run-hooks (quote gnus-article-prepare-hook)) (when gnus-show-mime (if ... ... ...)) (gnus-run-hooks (quote gnus-article-display-hook)))
  (progn (let (buffer-read-only) (gnus-run-hooks ...) (gnus-run-hooks ...) (when gnus-show-mime ...) (gnus-run-hooks ...)) (goto-char (point-min)) (setq gnus-page-broken (when gnus-break-pages ... t)))
  (if (or (numberp article) (stringp article)) (progn (let ... ... ... ... ...) (goto-char ...) (setq gnus-page-broken ...)))
  (when (or (numberp article) (stringp article)) (let (buffer-read-only) (gnus-run-hooks ...) (gnus-run-hooks ...) (when gnus-show-mime ...) (gnus-run-hooks ...)) (goto-char (point-min)) (setq gnus-page-broken (when gnus-break-pages ... t)))
  (if (or (eq result ...) (eq result ...)) (progn (save-excursion ... ... ... ... ...) (gnus-set-mode-line ...)) (when (and ... ...) (save-excursion ... ... ... ... ... ... ... ... ... ... ...)) (when (or ... ...) (let ... ... ... ... ...) (goto-char ...) (setq gnus-page-broken ...)) (gnus-set-mode-line (quote article)) (gnus-configure-windows (quote article)) (goto-char (point-min)) (search-forward "\n\n" nil t) (set-window-point (get-buffer-window ...) (point)) t)
  (if (not (setq result ...)) (save-excursion (when ... ... ... ... ...)) (if (or ... ...) (progn ... ...) (when ... ...) (when ... ... ... ...) (gnus-set-mode-line ...) (gnus-configure-windows ...) (goto-char ...) (search-forward "\n\n" nil t) (set-window-point ... ...) t))
  (save-excursion (gnus-article-setup-buffer) (set-buffer gnus-article-buffer) (when (and ... transient-mark-mode) (setq mark-active nil)) (if (not ...) (save-excursion ...) (if ... ... ... ... ... ... ... ... ... t)))
  (let* ((gnus-article ...) (summary-buffer ...) (gnus-tmp-internal-hook gnus-article-internal-prepare-hook) (group gnus-newsgroup-name) result) (save-excursion (gnus-article-setup-buffer) (set-buffer gnus-article-buffer) (when ... ...) (if ... ... ...)))
  (save-excursion (unless (eq major-mode ...) (set-buffer gnus-summary-buffer)) (setq gnus-summary-buffer (current-buffer)) (let* (... ... ... ... result) (save-excursion ... ... ... ...)))
  gnus-article-prepare(5592 nil)
  (if gnus-summary-display-article-function (funcall gnus-summary-display-article-function article all-header) (gnus-article-prepare article all-header))
  (prog1 (if gnus-summary-display-article-function (funcall gnus-summary-display-article-function article all-header) (gnus-article-prepare article all-header)) (gnus-run-hooks (quote gnus-select-article-hook)) (when (and gnus-current-article ...) (gnus-summary-goto-subject gnus-current-article)) (gnus-summary-recenter) (when (and gnus-use-trees gnus-show-threads) (gnus-possibly-generate-tree article) (gnus-highlight-selected-tree article)) (gnus-article-set-window-start (cdr ...)))
  (if (null article) nil (prog1 (if gnus-summary-display-article-function ... ...) (gnus-run-hooks ...) (when ... ...) (gnus-summary-recenter) (when ... ... ...) (gnus-article-set-window-start ...)))
  gnus-summary-display-article(5592)
  (or (gnus-summary-display-article (gnus-summary-article-number)) (eq (gnus-summary-article-mark) gnus-canceled-mark))
  (and (gnus-summary-search-forward unread subject backward) (or (gnus-summary-display-article ...) (eq ... gnus-canceled-mark)))
  (cond ((and ... ...) (gnus-summary-position-point)) ((and subject gnus-auto-select-same ...) (gnus-summary-position-point) (gnus-message 6 "Wrapped")) ((and gnus-auto-extend-newsgroup ... ...) (gnus-summary-goto-article ... nil ...)) (t (unless ... ...) (let ... ... ...)))
  gnus-summary-next-article(nil)
* call-interactively(gnus-summary-next-article)

Re: Hallvard's gnus-e20/19.34/Pgnus 0.13 emulation (backtrace included)

[Hrvoje Niksic]

<jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

>     
>     I'm having great success running Pgnus with 19.34, but then I hit this.
>     (Thanks Hallvard's for gnus-e20.el)
> 
>         (gnus-version)"Pterodactyl Gnus v0.13
> 
>     Does string-to-number take new parameter in Emacs 20.x ?

As a matter of fact, yes.  It supports an optional BASE argument.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
A jury consists of 12 persons chosen to decide who has the better
lawyer.

Re: Hallvard's gnus-e20/19.34/Pgnus 0.13 emulation (backtrace included)

[Lars Magne Ingebrigtsen]

<jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

> Does string-to-number take new parameter in Emacs 20.x ?

Yes; the radix.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Suggestion: to problem nndraft "Can't select group"

[Jari Aalto+list.ding]

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


    Hi,

    I posted before question why I couldn't select nndraft group which did
    contain articles if I looked into directory. The server was open, the
    path was okay, but still I got message

        Can't select group

    After lot of Edebugging, i found out that I was missing entry

        (display . all)

    from the Group parameters. After I put it there, the articles were read
    and I could access nndraft. I think it would be good idea to add that
    group parameter by default in the nndraft groups so that user don't get
    confused about the misleding "Can't select group" message.

    jari


[-- Attachment #2: Type: text/plain, Size: 1885 bytes --]


THE INITIAL SITUATION

              (gnus-select-newsgroup "nndraft:drafts" t)
                gnus-articles-to-read
              --> Can't select group

    gnus-select-newsgroup called gnus-articles-to-read but it didn't find
    anything. cond statement in gnus-articles-to-read triggered 0, thus
    returning nil back, and hence error message


(defun gnus-select-newsgroup (group &optional read-all select-articles)
    ;; Adjust and set lists of article marks.
    (when info
      (gnus-adjust-marked-articles info))

info --> ("nndraft:drafts" 1 nil nil (nndraft "") ((timestamp 13711 39412) (expiry-wait . 5) (total-expire . t) (gnus-dummy (gnus-draft-mode))))

    (if (setq articles select-articles)
        (setq gnus-newsgroup-unselected
              (gnus-sorted-intersection
               gnus-newsgroup-unreads
               (gnus-sorted-complement gnus-newsgroup-unreads articles)))
      (setq articles (gnus-articles-to-read group read-all)))


    (if (setq articles select-articles)
--> nil 
      (setq articles (gnus-articles-to-read group read-all)))
--> 0

and later the cond statement in gnus-select-newsgroup

     ((eq articles 0) nil)


(defun gnus-articles-to-read (group &optional read-all)
  ;; Find out what articles the user wants to read.
  (let* ((articles
          ;; Select all articles if `read-all' is non-nil, or if there
          ;; are no unread articles.
          (if (or read-all
                  (and (zerop (length gnus-newsgroup-marked))
--> '(19)       
                       (zerop (length gnus-newsgroup-unreads)))
--> nil

        articles
--> nil 


AFTER I PUT (display . all) TO GROUP PARAMETER    


info --> ("nndraft:drafts" 1 ((1 . 133) 135 (137 . 140) (142 . 143) (145 . 155) (157 . 163) (165 . 170)) nil (nndraft "") ((timestamp 13806 46863) (expiry-wait . 5) (total-expire . t) (gnus-dummy (gnus-draft-mode))))

Re: Suggestion: to problem nndraft "Can't select group"

[David S. Goldberg]

I have no idea what you may be doing wrong, but (display . all) isn't
it.  I do not have (display . all) set for my nndraft group and have
no trouble with it whatsoever.  I even tested it by saving this
message with message-dont-send, going into the draft group (there it
was as expected), then doing a catchup and selecting it again from the
*Group* buffer.  I got into the group as expected and ran D e and in a
couple of seconds I will send it out.

--
Dave Goldberg
Post: The Mitre Corporation\MS B305\202 Burlington Rd.\Bedford, MA 01730
Phone: 781-271-3887
Email: dsg@mitre.org

Re: Suggestion: to problem nndraft "Can't select group"

[Jari Aalto+list.ding]

| 1998-09-03 dsg@mitre.org (David S. Goldberg) list.ding
| I have no idea what you may be doing wrong, but (display . all) isn't
| it.  I do not have (display . all) set for my nndraft group and have
| no trouble with it whatsoever.  I even tested it by saving this
| message with message-dont-send, going into the draft group (there it
| was as expected), then doing a catchup and selecting it again from the
| *Group* buffer.  I got into the group as expected and ran D e and in a
| couple of seconds I will send it out.

I can't be absolutely positive what was the problem, because I ran
Edebug 2 hours and added lot of test code inside functions it
it used. All just suddendly working after I added (display . all),
because then it triggered following function to find my lost nndraft
afticles. I think adding that parameter by default in nndraft is
goo idea to prevent any similar event happening.

My situation was different than yours: I hadn't have working nndraft
for months, so I couldn't just "remove" or "add" that display
property to see if it changed anything.


(defun gnus-articles-to-read (group &optional read-all)
  ;; Find out what articles the user wants to read.
  (let* ((articles
          ;; Select all articles if `read-all' is non-nil, or if there
          ;; are no unread articles.
          (if (or read-all
                  (and (zerop (length gnus-newsgroup-marked))
                       (zerop (length gnus-newsgroup-unreads)))
                  (eq (gnus-group-find-parameter group 'display)
                      'all))
                   |
                   |
                   This

Side note: (do not be concerned, I'll investigate this first) I'm
wondering why

    nndraft-request-group

keeps at value 'ignore, due to statement:

    (eval-when-compile
      (require 'cl)
      ;; This is just to shut up the byte-compiler.
      (fset 'nndraft-request-group 'ignore))

While the nnoo-import at the end of nndraft.el should wipe it away. It
doesn't do that for me for some very mysterious reason. I'll take a look at
it next time I boot Gnus down and up.


jari

Re: Suggestion: to problem nndraft "Can't select group"

[Lars Magne Ingebrigtsen]

<jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

> I posted before question why I couldn't select nndraft group which did
> contain articles if I looked into directory. The server was open, the
> path was okay, but still I got message
> 
> Can't select group

`M-g' the group.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Patch: be verbose if POP3 setup is not ok

[Jari Aalto+list.ding]

    Hi,

    I'm currently trying to get my 2 POP3 acocunts integrated with gnus
    and in the process I thought this would be nicer message to
    user than just an cryptic error.

    Patch is against pgnus 0.13

    jari

--- nnmail.el.orig-p0.13	Tue Sep  8 18:51:35 1998
+++ nnmail.el	Tue Sep  8 19:04:48 1998
@@ -629,6 +629,17 @@
 			 (set-buffer errors)
 			 (insert (prin1-to-string err))
 			 (setq result 255))))
+		  ;; expand-file-name below breaks if we don't check this.
+		  (unless (stringp nnmail-movemail-program)
+		    (with-output-to-temp-buffer "*Gnus Error*"
+		      (princ
+		       (message
+			(concat "Your nnmail-movemail-program must be string "
+				"or callable lisp function. \nPlease check "
+				"your setup. Value was [%s]")
+			(prin1-to-string nnmail-movemail-program))))
+		    (error "Gnus: Error, Check nnmail-movemail-program"))
 		  (let ((default-directory "/"))
 		    (setq result
 			  (apply

Re: Patch: be verbose if POP3 setup is not ok

[Lars Magne Ingebrigtsen]

<jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

> I'm currently trying to get my 2 POP3 acocunts integrated with gnus
> and in the process I thought this would be nicer message to
> user than just an cryptic error.

[...]

> +		  ;; expand-file-name below breaks if we don't check this.
> +		  (unless (stringp nnmail-movemail-program)
> +		    (with-output-to-temp-buffer "*Gnus Error*"
> +		      (princ
> +		       (message
> +			(concat "Your nnmail-movemail-program must be string "
> +				"or callable lisp function. \nPlease check "
> +				"your setup. Value was [%s]")
> +			(prin1-to-string nnmail-movemail-program))))
> +		    (error "Gnus: Error, Check nnmail-movemail-program"))

There are a gazillion variables that can be strings, symbols, list or
numbers, and if I were to add error messages like these to them all,
Gnus would swell to several gazillion megabytes.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Patch: be verbose if POP3 setup is not ok

[Jari Aalto+list.ding]

| 1998-09-08 Lars Magne Ingebrigtsen <larsi@gnus.org> list.ding
| <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:
| 
| > +             ;; expand-file-name below breaks if we don't check this.
| > +             (unless (stringp nnmail-movemail-program)
| > +               (with-output-to-temp-buffer "*Gnus Error*"
| > +                 (princ
| > +                  (message
| > +                   (concat "Your nnmail-movemail-program must be string "
| > +                           "or callable lisp function. \nPlease check "
| > +                           "your setup. Value was [%s]")
| > +                   (prin1-to-string nnmail-movemail-program))))
| > +               (error "Gnus: Error, Check nnmail-movemail-program"))
| 
| There are a gazillion variables that can be strings, symbols, list or
| numbers, and if I were to add error messages like these to them all,
| Gnus would swell to several gazillion megabytes.

Hoabout just adding the last `error' command in this case?
The movemail setup is quite curcial if one starts to play with it
(eg pop3 in my case)

jari

Re: Patch: be verbose if POP3 setup is not ok

[Per Abrahamsen]

<jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

> The movemail setup is quite curcial if one starts to play with it
> (eg pop3 in my case)

Users who can't figure out the Lisp types should use the custom
interface to set options.

Re: Patch: be verbose if POP3 setup is not ok

[Jari Aalto+list.ding]

| 1998-09-09 Per Abrahamsen <abraham@dina.kvl.dk> list.ding
| <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:
| 
| > The movemail setup is quite curcial if one starts to play with it
| > (eg pop3 in my case)
| 
| Users who can't figure out the Lisp types should use the custom
| interface to set options.

I see nothing wrong in improving the error checking in selected
parts of the code. Mistakes do happen and this time the type was
correct when I set it. it was a lisp function symbol, but
it wasn't fbound (I forgot to add autoload) so the Gnus went
ahead to used it as shell command. Yes, It was my mistake,
but it would have been good to test stringp/error before doing
expand-file-name. That would have been more informative error.

jari

compatibility request -- `q' in *Article* buffer shouldn't quit group

[SL Baur]

Could `q' from inside the *Article* buffer please return to the
*Summary* buffer the same way it did with TM?

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Lars Magne Ingebrigtsen]

SL Baur <steve@xemacs.org> writes:

> Could `q' from inside the *Article* buffer please return to the
> *Summary* buffer the same way it did with TM?

Er...  I don't know.  `h' is the traditional way of skipping between
the article and summary buffers.  `q' has always meant `quit', in one
form or another.  (Except in TM, that is.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Michael Harnois]

Kurt Swanson <ksw@dna.lth.se> writes:

> SL Baur <steve@xemacs.org> writes:
> > Could `q' from inside the *Article* buffer please return to the
> > *Summary* buffer the same way it did with TM?
> 
> No.  Use `h' or `='.  `q' is for quitting the group.

Excuse me? And who died and made you God?

--
Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA 
mharnois@sbt.net                      aa0bt@aa0bt.ampr.org 
  Sed quis custodiet ipsos custodes? -- Juvenal

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Hrvoje Niksic]

Michael Harnois <mharnois@sbt.net> writes:

> Kurt Swanson <ksw@dna.lth.se> writes:
> 
> > SL Baur <steve@xemacs.org> writes:
> > > Could `q' from inside the *Article* buffer please return to the
> > > *Summary* buffer the same way it did with TM?
> > 
> > No.  Use `h' or `='.  `q' is for quitting the group.
> 
> Excuse me? And who died and made you God?

I will, if needs be.  `q' has always exited to Group buffer, and some
of us haven't even seen TM.  Compatibility with Gnus should be much
more important than compatibility with TM.

`h' has always been there to switch to Summary.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Try to use "ad nauseam" at least once per flame. It doesn't mean
anything; but it gives that polished feel to your postings.

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Michael Harnois]

Hrvoje Niksic <hniksic@srce.hr> writes:

> I will, if needs be.

God? Or dead? <g>

--
Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA 
mharnois@sbt.net                      aa0bt@aa0bt.ampr.org 
  Sed quis custodiet ipsos custodes? -- Juvenal

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Michael Harnois]

Kurt Swanson <ksw@dna.lth.se> writes:

> Your asinine behaviour cannot be excused.

I'm afraid you have the shoe on the wrong foot. You're the one who
acted like an ass. I merely pointed it out. I'm sure that's
uncomfortable for you, but the cure would be not to do it.

--
Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA 
mharnois@sbt.net                      aa0bt@aa0bt.ampr.org 
  Sed quis custodiet ipsos custodes? -- Juvenal

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Lars Magne Ingebrigtsen]

Michael Harnois <mharnois@sbt.net> writes:

> You're the one who acted like an ass.

I'm all for flame fests -- any time, any where -- but can't it be
about something a bit more important than keymaps?  Like -- choice of
highlighting in the Tree buffer?  *Now* we're talking religious issues!

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Matt Simmons]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    sb> Could `q' from inside the *Article* buffer please return to the
    sb> *Summary* buffer the same way it did with TM?

    Lars> Er...  I don't know.  `h' is the traditional way of skipping between
    Lars> the article and summary buffers.  `q' has always meant `quit', in one
    Lars> form or another.  (Except in TM, that is.)

Well, if you think of it as a hierarchy (group, summary, article),
then using `q' to return to the summary buffer makes sense.  You're
using `q' to quit the article buffer, thus returning to the summary
buffer, just as you use `q' to quit the summary buffer, returning you
to the group buffer.

Matt

-- 
     Matt Simmons  -  simmonmt@acm.org  -  http://www.netcom.com/~simmonmt
       "No animal should ever jump up on the dining-room furniture unless
       absolutely certain that he can hold his own in the conversation."
				-- Fran Lebowitz

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Hrvoje Niksic]

Matt Simmons <simmonmt@acm.org> writes:

> >>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
>     sb> Could `q' from inside the *Article* buffer please return to the
>     sb> *Summary* buffer the same way it did with TM?
> 
>     Lars> Er...  I don't know.  `h' is the traditional way of
>     Lars> skipping between the article and summary buffers.  `q' has
>     Lars> always meant `quit', in one form or another.  (Except in
>     Lars> TM, that is.)
> 
> Well, if you think of it as a hierarchy (group, summary, article),
> then using `q' to return to the summary buffer makes sense.

Article buffer is not a part of that hierarchy.  For example, pressing 
RET or SPC doesn't get you to the Article buffer.

A while ago, someone has asked Lars to make `q' in Summary buffer
perform `/ w' if there are any limits available.  Lars refused because 
he thought that `q' shouldn't change its meaning.  I agree.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
* Q: What is an experienced Emacs user?
* A: A person who wishes that the terminal had pedals.

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Michael Harnois <mharnois@sbt.net> writes:
> 
> > You're the one who acted like an ass.
> 
> I'm all for flame fests -- any time, any where -- but can't it be
> about something a bit more important than keymaps?  Like -- choice
> of highlighting in the Tree buffer?  *Now* we're talking religious
> issues!

Huh?!

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it."                                    -- Donald Knuth

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Huh?!

S'a joke.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Julian Assange]

Michael Harnois <mharnois@sbt.net> writes:

> Kurt Swanson <ksw@dna.lth.se> writes:
> 
> > SL Baur <steve@xemacs.org> writes:
> > > Could `q' from inside the *Article* buffer please return to the
> > > *Summary* buffer the same way it did with TM?
> > 
> > No.  Use `h' or `='.  `q' is for quitting the group.
> 
> Excuse me? And who died and made you God?

Nietzsche?

Julian.

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[SL Baur]

Hrvoje Niksic <hniksic@srce.hr> writes in ding@gnus.org:

Lars> Er...  I don't know.  `h' is the traditional way of
Lars> skipping between the article and summary buffers.  `q' has
Lars> always meant `quit', in one form or another.  (Except in
Lars> TM, that is.)

I lost count of the number it times it bit me when I was experimenting 
with pgnus yesterday.  If group (re)entry weren't so bloody slow on
large groups it might not be much of an issue.

A lot of people use TM with Gnus and we're going to be in a world of
unnecessary pain.

>> Well, if you think of it as a hierarchy (group, summary, article),
>> then using `q' to return to the summary buffer makes sense.

Yes, it does make sense.

> Article buffer is not a part of that hierarchy.  For example, pressing 
> RET or SPC doesn't get you to the Article buffer.

?  SPC should probably do a page forward, or move to the next MIME
multipart.

> A while ago, someone has asked Lars to make `q' in Summary buffer
> perform `/ w' if there are any limits available.  Lars refused because 
> he thought that `q' shouldn't change its meaning.  I agree.

Hmm.  Widening would make more sense.  I haven't checked recently, but
the last time I entered a digest, hitting a `q' (in the *Summary*
buffer not *Article* buffer) popped the digest but didn't exit the
group.

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Hrvoje Niksic]

SL Baur <steve@xemacs.org> writes:

> I lost count of the number it times it bit me when I was experimenting 
> with pgnus yesterday.

Yes, but that's because you are accustomed to TM.  If it weren't for
this TM's design decision, you would probably not do that.

> > Article buffer is not a part of that hierarchy.  For example,
> > pressing RET or SPC doesn't get you to the Article buffer.
> 
> ?  SPC should probably do a page forward, or move to the next MIME
> multipart.

What I mean is: pressing SPC in the Group buffer switches you to
Summary.  But pressing SPC in the Summary buffer doesn't switch you to
Article buffer.  This is why I think there is no good reason to make
`q' in Article buffer switch to Summary.

Especially when we already have two commands to do that (`h' and `s').
Adding a fourth one looks like a real waste to me.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
If we get involved in a nuclear war, will the electromagnetic pulses
from exploding bombs damage my videotapes?

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[SL Baur]

Hrvoje Niksic <hniksic@srce.hr> writes in ding@gnus.org:

> SL Baur <steve@xemacs.org> writes:
>> I lost count of the number it times it bit me when I was experimenting 
>> with pgnus yesterday.

> Yes, but that's because you are accustomed to TM.  If it weren't for
> this TM's design decision, you would probably not do that.

That's exactly the point.  TM has been around for a *long* time -- as
long as Gnus 5 has been in existence.  The Gnus FAQ recommended it
practically from day 1.  It has been the default MIME package in
XEmacs since XEmacs 19.15.  Gnus is now taking over that area itself
and it really should preserve backwards compatibility particularly
with respect to user interface.  This isn't any different than the way
message mode preserves the same keybindings of the ancient mail-mode.

 ...
> What I mean is: pressing SPC in the Group buffer switches you to
> Summary.  But pressing SPC in the Summary buffer doesn't switch you to
> Article buffer.  This is why I think there is no good reason to make
> `q' in Article buffer switch to Summary.

> Especially when we already have two commands to do that (`h' and `s').
> Adding a fourth one looks like a real waste to me.

Gnus is *changing* the binding of `q' which formerly meant quit the
MIME viewer and return to the *Summary* buffer to exit the group.
This is dead wrong IMO.

There's similar braindamage in BBDB 2 -- the M-TAB fuckage it
introduced has got to go.  That key belongs to ispell.

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Hrvoje Niksic]

SL Baur <steve@xemacs.org> writes:

> > Yes, but that's because you are accustomed to TM.  If it weren't for
> > this TM's design decision, you would probably not do that.
> 
> That's exactly the point.  TM has been around for a *long* time --
> as long as Gnus 5 has been in existence.  The Gnus FAQ recommended
> it practically from day 1.  It has been the default MIME package in
> XEmacs since XEmacs 19.15.  Gnus is now taking over that area itself
> and it really should preserve backwards compatibility particularly
> with respect to user (...)

The phrase "backward compatibility" cannot apply here because TM has
never been a part of Gnus.  People who used TM did so "on their own
responsibility".  Incompatibly changing Gnus to satisfy former TM
users would IMHO be plain wrong.

> > What I mean is: pressing SPC in the Group buffer switches you to
> > Summary.  But pressing SPC in the Summary buffer doesn't switch
> > you to Article buffer.  This is why I think there is no good
> > reason to make `q' in Article buffer switch to Summary.
> 
> > Especially when we already have two commands to do that (`h' and
> > `s').  Adding a fourth one looks like a real waste to me.
> 
> Gnus is *changing* the binding of `q' which formerly meant quit the
> MIME viewer

There never was any MIME viewer in Gnus.

> There's similar braindamage in BBDB 2 -- the M-TAB fuckage it
> introduced has got to go.  That key belongs to ispell.

M-TAB was bound to `lisp-complete-symbol' until recently.  The ispell
binding is IMHO useless because there are too many possibilities for
the completion attempt to be useful.  But this is a totally different
issue.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Ask not for whom the <CONTROL-G> tolls.

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Karl Kleinpaste]

You're splitting semantic hairs that are already exceptionally fine.

While technically not distributed as part of Gnus, TM has been "part
of Gnus" insofar as Gnus explicitly referred everyone to TM.  The
exercise of "their own responsibility" necessary to use TM consists of
a single load directive, nothing more.  People have been using TM, and
*only* TM, as "Gnus' MIME viewer" for years.  Breaking those habits
should be done with care.

You might as well stop telling people to adjust their mail addresses
with user-mail-address, because the definition of user-mail-address
"isn't part of Gnus."

Personally, I *do* think of group/summary/article as a hierarchy, for
increasing precision: I get a big overview in *Group*, I see per-group
specifics in *Summary*, and I get down and dirty with a particular
piece of text by hitting buttonized content in *Article*.  I think
having `q' go back to *Summary* is a dandy idea...and I wasn't even
aware until this discussion that TM did so.

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Hrvoje Niksic]

Karl Kleinpaste <karl@jprc.com> writes:

> While technically not distributed as part of Gnus, TM has been "part
> of Gnus" insofar as Gnus explicitly referred everyone to TM.

I cannot find such a reference in the manual, except for an FAQ entry.

> The exercise of "their own responsibility" necessary to use TM
> consists of a single load directive, nothing more.

I agree that it was easy to load TM.  It says nothing about it being a 
part of Gnus.  It's always been an extension package.

> People have been using TM, and *only* TM, as "Gnus' MIME viewer" for
> years.  Breaking those habits should be done with care.

This is patently false.  People have also been using rmime.  I didn't
want to have anything to do with TM because of its extremely ugly
user-interface.  As for breaking habits, many habits were broken by
introducing message-mode instead of mail and news modes, and yet the
users adapted.

> You might as well stop telling people to adjust their mail addresses
> with user-mail-address, because the definition of user-mail-address
> "isn't part of Gnus."

?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Ask not for whom the <CONTROL-G> tolls.

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Kai Grossjohann]

>>>>> SL Baur <steve@xemacs.org> writes:

  > Hmm.  Widening would make more sense.  I haven't checked recently, but
  > the last time I entered a digest, hitting a `q' (in the *Summary*
  > buffer not *Article* buffer) popped the digest but didn't exit the
  > group.

`q' exited the digest group.  At least that's what `q' has done for me
in a digest group, for a long time now.

kai
-- 
OOP: object oriented programming;  OOPS: object oriented mistakes

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Kai Grossjohann]

I'm not sure about all this.

OT1H, there was metamail.el and rmime.el, both of which did the MIME
thing alright.  So one can't really say that everybody who wanted a
MIMEy Gnus has used TM.

OTOH, the article buffer is getting to be more like a group, what with
multipart messages, so it seems that the group-summary-article
hierarchy is a valid thing.

I'm sure that we can't satisfy everybody's need.  In the end, all we
can do is toss a coin.  And then, why don't we all just accept Lars'
wishes, he's got a certain right to have Gnus working the way he wants
it, after all :-)

It would be nice, though, to have an easily-customizable variable
`gnus-mime-be-like-tm' or something.  Hm.  But that would be ugly.

kai
-- 
OOP: object oriented programming;  OOPS: object oriented mistakes

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Lloyd Zusman]

Karl Kleinpaste <karl@jprc.com> writes:

> You're splitting semantic hairs that are already exceptionally fine.
> 
> While technically not distributed as part of Gnus, TM has been "part
> of Gnus" insofar as Gnus explicitly referred everyone to TM.  The
> exercise of "their own responsibility" necessary to use TM consists of
> a single load directive, nothing more.  People have been using TM, and
> *only* TM, as "Gnus' MIME viewer" for years.  Breaking those habits
> should be done with care.
> 
> [ ... ]

How about something like this:

In `gnus.el' ...

  (defvar gnus-tm-compatibility nil
    "*TM compatibility.")

In `gnus-art.el' ...

  (when gnus-tm-compatibility
    (gnus-define-keys gnus-article-mode-map
      "q" gnus-article-show-summary))

... or at least something similar.

Would this solution be a "win-win situation", or does this just shift
the flame w^H^H^H^H^H^H^Hdebate to the question of whether to use
`nil' or `t' in the `defvar' above?  :)

> [ ... ]

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Lars Magne Ingebrigtsen]

Lloyd Zusman <ljz@asfast.com> writes:

> How about something like this:
> 
> In `gnus.el' ...
> 
>   (defvar gnus-tm-compatibility nil
>     "*TM compatibility.")

No.  Keymaps that change according to variables like this is very
confusing, both to me and to users.  ("And then I press 'q', and
flargbnoze happens."  "Er.  Which 'q'?")

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Per Abrahamsen]

Karl Kleinpaste <karl@jprc.com> writes:

> People have been using TM, and
> *only* TM, as "Gnus' MIME viewer" for years. 

Uh, I'm using metamail.el, and am quite happy with it.

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Jari Aalto+list.ding]

| 1998-10-11 Hrvoje Niksic <hniksic@srce.hr> list.ding
| SL Baur <steve@xemacs.org> writes:
| > 
| > That's exactly the point.  TM has been around for a *long* time --
| > as long as Gnus 5 has been in existence.  
| 
| The phrase "backward compatibility" cannot apply here because TM has
| never been a part of Gnus.  People who used TM did so "on their own
| responsibility".  Incompatibly changing Gnus to satisfy former TM
| users would IMHO be plain wrong.

C'mon. You're splitting hairs here. TM has been practically the de facto
standard for MIME since day 1 when it come in picture. Just like Gnus is
the de facto standard for News reading.

TM has supported every major MUA platform and it should be treated as respectfully
as GNUS in spite of the decisions of not integrating TM into Gnus. There are lot
of people that use TM with gnus and continue to do so as long as it works.

I also agree with steve, that SPC/BACKSPACE should go to next/prev mime section.

jari

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Hrvoje Niksic]

<jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

> | The phrase "backward compatibility" cannot apply here because TM has
> | never been a part of Gnus.  People who used TM did so "on their own
> | responsibility".  Incompatibly changing Gnus to satisfy former TM
> | users would IMHO be plain wrong.
> 
> C'mon. You're splitting hairs here. TM has been practically the de
> facto standard for MIME since day 1 when it come in picture.

Assert this many times won't make it less false than it was the first
time around: many people haven't used TM.  Many haven't even seen it.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
* Q: What is an experienced Emacs user?
* A: A person who wishes that the terminal had pedals.

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Lloyd Zusman]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Lloyd Zusman <ljz@asfast.com> writes:
> 
> > How about something like this:
> > 
> > In `gnus.el' ...
> > 
> >   (defvar gnus-tm-compatibility nil
> >     "*TM compatibility.")
> 
> No.  Keymaps that change according to variables like this is very
> confusing, both to me and to users.  ("And then I press 'q', and
> flargbnoze happens."  "Er.  Which 'q'?")

Well, so much for diplomacy. :)

And once we reach the letter `f' for the leading initial of the newest
Gnus release (i.e., `fgnus'), I have the perfect name:

  Flargbnoze Gnus

It has a certain ring to it, especially if none of the letters are
silent ...


So anyway ... how about this second attempt at diplomacy:

Somewhere amidst the Gnus documentation (and perhaps on one of the
www.gnus.org pages, as well), place this code snippet for easy
copy-and-paste-ing ...

  ;; Insert this optional piece of code into your .gnus.el file for 
  ;; TM compatibility.
  (add-hook 'gnus-article-mode-hook
   '(lambda ()
      (gnus-define-keys gnus-article-mode-map
       "q" gnus-article-show-summary)))



-- 
 Lloyd Zusman
 ljz@asfast.com

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Robert Pluim]

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic@srce.hr> writes:

    Hrvoje> <jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

    >> | The phrase "backward compatibility" cannot apply here because
    >> TM has | never been a part of Gnus.  People who used TM did so
    >> "on their own | responsibility".  Incompatibly changing Gnus to
    >> satisfy former TM | users would IMHO be plain wrong.
    >>
    >> C'mon. You're splitting hairs here. TM has been practically the
    >> de facto standard for MIME since day 1 when it come in picture.

    Hrvoje> Assert this many times won't make it less false than it
    Hrvoje> was the first time around: many people haven't used TM.
    Hrvoje> Many haven't even seen it.

TM? Mime? What's that? If a news article contains stuff that a human
can't decode easily, I skip it :-) [1][2]

Robert

Footnotes: 
[1]  yes, I know about W m

[2]  I don't want no steenking HTML in postings

-- 
Robert Pluim                                 Tel:  +33 4 92 96 17 43
Systems Development Engineer                 Fax:  +33 4 92 96 15 32
<URL: mailto:rpluim@baynetworks.com>
Bay Networks EMEA,  25 Allee Pierre Ziller,  06560 Valbonne,  France

Re: compatibility request -- `q' in *Article* buffer shouldn't quit group

[Lars Magne Ingebrigtsen]

Lloyd Zusman <ljz@asfast.com> writes:

> Somewhere amidst the Gnus documentation (and perhaps on one of the
> www.gnus.org pages, as well), place this code snippet for easy
> copy-and-paste-ing ...
> 
>   ;; Insert this optional piece of code into your .gnus.el file for 
>   ;; TM compatibility.
>   (add-hook 'gnus-article-mode-hook
>    '(lambda ()
>       (gnus-define-keys gnus-article-mode-map
>        "q" gnus-article-show-summary)))

It's still the same thing, only said in a different way.

Some people do not use a summary buffer.  For these people, having the
`q' command really mean "quit" is essential.  Having `q' skip back to
the summary buffer (that holds no interest for them) is not a good
idea.

The people who really want `q' to do `h' (and know that they don't
need the normal `q' meaning in the article buffer) can `local-set-key'
this themselves in `gnus-article-mode-map'.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Pterodactyl Gnus v0.36 is released

[Lars Magne Ingebrigtsen]

Bug fixes and nested multipart stuff.

Get it from <URL:http://www.gnus.org/pgnus.tar.gz> or
"/ftp@ftp.gnus.org:/pub/emacs/gnus/".  The patch is available as
<URL:http://www.gnus.org/patches/pgnus-0.35-0.36.diff.gz>.

ChangeLog since last release:

Tue Oct 20 20:25:03 1998  Lars Magne Ingebrigtsen  <larsi@menja.ifi.uio.no>

	* gnus.el: Pterodactyl Gnus v0.36 is released.

1998-10-20 18:13:08  Lars Magne Ingebrigtsen  <larsi@gnus.org>

	* gnus-art.el (article-translate-strings): 
	(gnus-article-dumbquotes-map): Don't dot.

	* pop3.el (pop3-open-server): Set point right.

	* mm-decode.el (mm-dissect-multipart): Dissect hierarchically. 
	(mm-dissect-buffer): Ditto.
	(mm-destroy-part): Ignore non-handles.
	(mm-remove-part): Ditto.
	(mm-destroy-parts): New function.
	(mm-remove-parts): Ditto.

	* gnus-art.el (gnus-mm-display-part): Don't move point.

Tue Oct 20 02:16:36 1998  Shenghuo ZHU  <zsh@cs.rochester.edu>

	* mm-uu.el : New file.
	
	* gnus-art.el (gnus-display-mime): Dissect uu stuffs.
	
	* mm-bodies.el (mm-decode-content-transfer-encoding): Encoding as
	a function.

1998-10-20 00:35:05  Lars Magne Ingebrigtsen  <larsi@gnus.org>

	* mm-decode.el (mm-display-external): Check before selecting.



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

*Group* buffer disappearance (Re: Pterodactyl Gnus v0.36 is released)

[Lloyd Zusman]

There's a bug that exists both in v0.35 and v0.36 whereby the *Group*
buffer seems to mysteriously disappear under certain circumstances.  I
don't think that this particular problem existed in versions <= v0.34.
 
I'm not sure what could be causing this.

Here's the scenario: 
 
(1)  View a message that has at least one `application/octet-stream' 
     MIME attachment. 
 
(2)  [Suppose that this is attachment number 2]  Enter the following  
     command:   `2 b' 
 
(3)  Prompt appears in the mini-buffer asking where to save the 
     attachment.  Enter a file name. 
 
(4)  Attachment gets nicely saved. 
 
(5)  Type `q' to leave summary mode and go back to *Group* buffer. 
 
(6)  The *Group* buffer seems to have disappeared, thereby
     signaling the following error:
 
Signaling: (error "Selecting deleted or non-existent buffer")
  #<compiled-function (from "gnus-sum.elc") (&optional temporary)
  "...(402)" [gnus-set-global-variables gnus-kill-save-kill-buffer
  gnus-async-halt-prefetch gnus-newsgroup-name group
  gnus-group-quit-config quit-config major-mode mode nil group-point buf
  gnus-run-hooks gnus-summary-prepare-exit-hook
  gnus-single-article-buffer gnus-original-article-buffer buffer
  get-buffer buffer-name kill-buffer gnus-article-current gnus-use-cache
  gnus-cache-possibly-remove-articles gnus-cache-save-buffers
  gnus-async-prefetch-remove-group gnus-suppress-duplicates
  gnus-dup-enter-articles gnus-use-trees gnus-tree-close
  nnmail-purge-split-history gname string-match "^[^:]+:" 0
  gnus-exit-group-hook gnus-summary-update-info gnus-newsgroup-adaptive
  gnus-score-adaptive gnus-use-scoring gnus-score-save gnus-close-group
  gnus-group-buffer gnus-group-jump-to-group gnus-summary-exit-hook
  gnus-group-group-name gnus-group-next-unread-group 1 temporary
  gnus-article-buffer mapcar ...] 5
  ("/usr/lib/xemacs/site-lisp/pgnus-0.36/lisp/gnus-sum.elc" . 139872)
  nil>()
  call-interactively(gnus-summary-exit)


Any ideas?

--  
 Lloyd Zusman 
 ljz@asfast.com

I fixed it, but I need Lars ... (Was: *Group* buffer disappearance)

[Lloyd Zusman]

Lloyd Zusman <ljz@asfast.com> writes:

> There's a bug that exists both in v0.35 and v0.36 whereby the *Group*
> buffer seems to mysteriously disappear under certain circumstances.
> [ ... ]

Well, I fixed the problem, but what a complex tangle of function calls
I had to go through to find it!

Also, I'm not sure if my fix is actually the best way to solve this
problem.  Lars, could you review my solution here to see if I've made
the correct assumptions in fixing it?

First of all, here's the patch which fixes the problem:

*** mm-decode.el.orig   Tue Oct 20 22:36:04 1998
--- mm-decode.el        Tue Oct 20 22:36:29 1998
***************
*** 221,227 ****
          (mm-set-buffer-file-coding-system 'no-conversion)
          (insert-buffer-substring cur)
          (funcall method)
!         (mm-handle-set-undisplayer handle (current-buffer)))
        (let* ((dir (make-temp-name (expand-file-name "emm." mm-tmp-directory)))
             (filename (mail-content-type-get
                        (mm-handle-disposition handle) 'filename))
--- 221,227 ----
          (mm-set-buffer-file-coding-system 'no-conversion)
          (insert-buffer-substring cur)
          (funcall method)
!         (mm-handle-set-undisplayer handle cur))
        (let* ((dir (make-temp-name (expand-file-name "emm." mm-tmp-directory)))
             (filename (mail-content-type-get
                        (mm-handle-disposition handle) 'filename))


Note that the problem had to do with the `(current-buffer)' call
immediately following `(funcall method)'.  When the method is
`mailcap-save-binary-file', this method causes the current buffer to
change (see below for a listing of `mailcap-save-binary-file').
Therefore, we need to use `cur' here instead of `(current-buffer)',
just like in the rest of this routine (`mm-display-external').

So far so good.  But does my solution just mask a more subtle problem?

Consider the `mailcap-save-binary-file' routine (in `mailcap.el'):

(defun mailcap-save-binary-file ()
  (goto-char (point-min))
  (let ((file (read-file-name
               "Filename to save as: "
               (or mailcap-download-directory "~/")))
        (require-final-newline nil))
    (write-region (point-min) (point-max) file)
    (kill-buffer (current-buffer))))

Note that the final line of this routine kills the current buffer,
However, when this routine is being called from within
`mm-display-external', the current buffer is one of the ` *mm*'
buffers.  Do we really want this ` *mm*' buffer to be killed as part
of the routine which saves the binary file?

If we do, then my patch is the proper fix.  However, if this ` *mm*'
buffer needs to stick around a while longer for some reason, then we
really shouldn't be using `mailcap-save-binary-file' in its current
form as the method call.

What do you think, Lars?

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance)

[Hrvoje Niksic]

Lloyd Zusman <ljz@asfast.com> writes:

> Note that the problem had to do with the `(current-buffer)' call
> immediately following `(funcall method)'.  When the method is
> `mailcap-save-binary-file', this method causes the current buffer to
> change (see below for a listing of `mailcap-save-binary-file').
> Therefore, we need to use `cur' here instead of `(current-buffer)',
> just like in the rest of this routine (`mm-display-external').

Killing `cur' doesn't look right.  The buffer you really want to kill
is the "*mm*" buffer, not the current buffer before that.  How about
this:

--- mm-decode.el.orig	Wed Oct 21 14:32:26 1998
+++ mm-decode.el	Wed Oct 21 14:35:45 1998
@@ -220,8 +220,10 @@
 	  (buffer-disable-undo)
 	  (mm-set-buffer-file-coding-system 'no-conversion)
 	  (insert-buffer-substring cur)
-	  (funcall method)
-	  (mm-handle-set-undisplayer handle (current-buffer)))
+	  (let ((mm (current-buffer)))
+	    (unwind-protect
+		(funcall method)
+	      (mm-handle-set-undisplayer handle mm))))
       (let* ((dir (make-temp-name (expand-file-name "emm." mm-tmp-directory)))
 	     (filename (mail-content-type-get
 			(mm-handle-disposition handle) 'filename))

I used `unwind-protect' so that if a signal occurs during the method,
the undisplayer still gets set.

(What I don't understand is why the undisplayer method still doesn't
get *called* when I press C-g.)

> Note that the final line of this routine kills the current buffer,
> However, when this routine is being called from within
> `mm-display-external', the current buffer is one of the ` *mm*'
> buffers.  Do we really want this ` *mm*' buffer to be killed as part
> of the routine which saves the binary file?

Yes.  The *mm* buffer is temporary stuff used for decoding MIME.  We
don't want buffers with random binary contents to stick around, I
think.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Psychos _do not_ explode when sunlight hits them."

Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance)

[Lloyd Zusman]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Lloyd Zusman <ljz@asfast.com> writes:
> 
> > Note that the problem had to do with the `(current-buffer)' call
> > immediately following `(funcall method)'.  When the method is
> > `mailcap-save-binary-file', this method causes the current buffer to
> > change (see below for a listing of `mailcap-save-binary-file').
> > Therefore, we need to use `cur' here instead of `(current-buffer)',
> > just like in the rest of this routine (`mm-display-external').
> 
> Killing `cur' doesn't look right.  The buffer you really want to kill
> is the "*mm*" buffer, not the current buffer before that.

Yes.  This seems correct, and it works under my test scenario.

> [ ... correct patch that appears elsewhere snipped ... ]

> I used `unwind-protect' so that if a signal occurs during the method,
> the undisplayer still gets set.
> 
> (What I don't understand is why the undisplayer method still doesn't
> get *called* when I press C-g.)

`unwind-protect' alone doesn't trap `C-g' signals.  I believe that you
have to make use of `condition-case' if you want to trap `C-g'.

I have to run to a meeting in a few minutes.  When I come back, I'll
redo your patch using `condition-case' and post it here.

> > Note that the final line of this routine kills the current buffer,
> > However, when this routine is being called from within
> > `mm-display-external', the current buffer is one of the ` *mm*'
> > buffers.  Do we really want this ` *mm*' buffer to be killed as part
> > of the routine which saves the binary file?
> 
> Yes.  The *mm* buffer is temporary stuff used for decoding MIME.  We
> don't want buffers with random binary contents to stick around, I
> think.

But by storing the name of the ` *mm*' buffer in the data structure
managed by `mm-handle-set-undisplayer', we're assuring that this
` *mm*' buffer gets deleted later.  Prior to this, should the buffer get
killed within the `mailcap-save-binary-file' method?  Would this
somehow cause problems later?

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance)

[Hrvoje Niksic]

Lloyd Zusman <ljz@asfast.com> writes:

> > (What I don't understand is why the undisplayer method still doesn't
> > get *called* when I press C-g.)
> 
> `unwind-protect' alone doesn't trap `C-g' signals.

I'm not talking about "trapping", but about evaluating the cleanup
code.  Try this:

(unwind-protect
    (sleep-for 5)
  (setq a (current-time-string)))

The point of this form is that `a' will end up being assigned even if
you exit from `sleep-for' nonlocally, such as with C-g.

> I have to run to a meeting in a few minutes.  When I come back, I'll
> redo your patch using `condition-case' and post it here.

Don't do that.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Call CIA and tell them that you have placed a bomb in a 7-11 shop!  Be
sure to let them trace you. Spend 10 years in jail and then regret it.

Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance)

[Lloyd Zusman]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Lloyd Zusman <ljz@asfast.com> writes:
> 
> > > (What I don't understand is why the undisplayer method still doesn't
> > > get *called* when I press C-g.)
> > 
> > `unwind-protect' alone doesn't trap `C-g' signals.
> 
> I'm not talking about "trapping", but about evaluating the cleanup
> code.

OK.

The call to `mm-handle-set-undisplayer' is indeed being made in your
`unwind-protect' version, even if `C-g' has been invoked.  However,
the `mm-handle-set-undisplayer' routine merely queues up the ` *mm*'
buffer for later undisplaying.  This undisplaying doesn't actually
occur until `gnus-summary-exit' gets invoked.  Here's the code
fragment within `gnus-summary-exit' which takes care of this:

      (when (gnus-buffer-live-p gnus-article-buffer)
        (save-excursion
          (set-buffer gnus-article-buffer)
          (mapcar 'mm-destroy-part gnus-article-mime-handles)))

Actually, this fragment exists within `gnus-summary-exit-no-update',
but that routine is normally defalias-ed to `gnus-summary-exit'.
There's also another place where this is also invoked ... I believe
its within the default `gnus-group-exit-hook'.

If we want to clean this up at the moment when someone hits `C-g',
then we may have to use `condition-case' after all.

> [ ... ]

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance)

[Hrvoje Niksic]

Lloyd Zusman <ljz@asfast.com> writes:

> If we want to clean this up at the moment when someone hits `C-g',
> then we may have to use `condition-case' after all.

Argh!  :-)  We don't.  We just add the same kind of cleanup code at
the place where the buffer normally gets deleted.  See my later patch.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
A jury consists of 12 persons chosen to decide who has the better
lawyer.

Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance)

[Lloyd Zusman]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Lloyd Zusman <ljz@asfast.com> writes:
> 
> > If we want to clean this up at the moment when someone hits `C-g',
> > then we may have to use `condition-case' after all.
> 
> Argh!  :-)  We don't.  We just add the same kind of cleanup code at
> the place where the buffer normally gets deleted.  See my later patch.

I await with bated breath! :)

I accept your point about not wanting to do the cleanup at the moment
`C-g' is invoked, but solely for my own education and edification (and
that of anyone else who might be interested), could you explain why an
immediate `C-g' trap is so undesirable at this point?

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance)

[Hrvoje Niksic]

Lloyd Zusman <ljz@asfast.com> writes:

> I accept your point about not wanting to do the cleanup at the
> moment `C-g' is invoked, but solely for my own education and
> edification (and that of anyone else who might be interested), could
> you explain why an immediate `C-g' trap is so undesirable at this
> point?

C-g trap is not undesirable; it's just that you're confusing
condition-case and unwind-protect.

condition-case should be used when you want to selectively trap errors
and do cleanup code.  What we need here is the cleanup code that
evaluates no matter what way we exit from the function -- including
C-g.  This is exactly what unwind-protect is for.

So, my patch adds unwind protection twice: once for the undisplayer to
be set, and once for the buffer to be killed after it is saved (or
not).  I hope this makes sense.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Do not meddle in the affairs of troff, for it is subtle and quick
to anger.

Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance)

[Lloyd Zusman]

Hrvoje Niksic <hniksic@srce.hr> writes:

> [ ... ]
>
> C-g trap is not undesirable; it's just that you're confusing
> condition-case and unwind-protect.
> 
> condition-case should be used when you want to selectively trap errors
> and do cleanup code.  What we need here is the cleanup code that
> evaluates no matter what way we exit from the function -- including
> C-g.  This is exactly what unwind-protect is for.
>
> So, my patch adds unwind protection twice: once for the undisplayer to
> be set, and once for the buffer to be killed after it is saved (or
> not).  I hope this makes sense.

It's clear to me now.  I had thought that the only time we would want
to clean up prior to `gnus-summary-exit' is if an error or an abort
occurred during the method call.  If we're supposed to be cleaning up
prior to `gnus-summary-exit' even in the case where the method
succeeds, then I understand why you're proceeding as you are.

... or at least I *think* I understand. :)

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance)

[Hrvoje Niksic]

Lloyd Zusman <ljz@asfast.com> writes:

> It's clear to me now.  I had thought that the only time we would
> want to clean up prior to `gnus-summary-exit' is if an error or an
> abort occurred during the method call.  If we're supposed to be
> cleaning up prior to `gnus-summary-exit' even in the case where the
> method succeeds, then I understand why you're proceeding as you are.

Well, that's what the code did before we started meddling, innit?  :-)

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
4.  Thou shalt not warlorde a sig if it bee the sig of Kibo, nor if
    it bee the sig of the Inner Circle.

Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance)

[Lloyd Zusman]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Lloyd Zusman <ljz@asfast.com> writes:
> 
> > It's clear to me now.  I had thought that the only time we would
> > want to clean up prior to `gnus-summary-exit' is if an error or an
> > abort occurred during the method call.  If we're supposed to be
> > cleaning up prior to `gnus-summary-exit' even in the case where the
> > method succeeds, then I understand why you're proceeding as you are.
> 
> Well, that's what the code did before we started meddling, innit?  :-)

I must be missing something, then.  The only places I have discovered
this cleanup being done in the pre-meddling version of the code is
during `gnus-summary-exit' and `gnus-group-exit-hook'.  Therefore,
I fully understand the need for putting an `unwind-protect' around 
`(funcall method)' ... but I don't understand the need for the other
`unwind-protect' that you mentioned in your previous message.

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance)

[Hrvoje Niksic]

Lloyd Zusman <ljz@asfast.com> writes:

> I must be missing something, then.  The only places I have
> discovered this cleanup being done in the pre-meddling version of
> the code is during `gnus-summary-exit' and `gnus-group-exit-hook'.
> Therefore, I fully understand the need for putting an
> `unwind-protect' around `(funcall method)' ... but I don't
> understand the need for the other `unwind-protect' that you
> mentioned in your previous message.

Think about it this way: again, that's what the code did before I
meddled.  The only thing I added is to make it do the same thing when
the user presses C-g at the save prompt.

The unwind-protect around (funcall method) is, I think, needed in case 
method is something other than save-file.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Depression is merely anger without enthusiasm.

Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance)

[Lee Willis]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Lloyd Zusman <ljz@asfast.com> writes:
> 
> Think about it this way: again, that's what the code did before I
> meddled.  The only thing I added is to make it do the same thing when
> the user presses C-g at the save prompt.
> 
> The unwind-protect around (funcall method) is, I think, needed in case 
> method is something other than save-file.

Hmm, well the bug can also be reproduced when you have a
multi-part/alternative message. E.g. I received a message with a
text/plain and text/html alternative part. Clicking (Or in my case
RET-ing) on the text/html part brings up a save prompt at which I give a
filename, gnus saves it OK, but my *Group* buffer has now taken a trip
to /dev/null :(

Lee.
-- 
I was doing object-oriented assembly at 1 year old ...  
For some reason my mom insists on calling it "Playing with blocks"

Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance)

[Jari Aalto+list.ding]

| 1998-10-21 Hrvoje Niksic <hniksic@srce.hr> list.ding
| 
| ...the cleanup code that evaluates no matter what way we exit from the
| function -- including C-g. This is exactly what unwind-protect is for.

This was something I wondered an hour ago in my own code. What
does "nonlocal" exist mean? And is it corect that cleanup is not done
if debug is on?

    (setq debug-on-error t)
    (unwind-protect
        (error)
      (insert "cleanup ok"))

The doc string of debug-on-error doesn't mention that the behavior
depends on debug-on-error setting...

jari
      

Re: I fixed it, but I need Lars ... (Was: *Group* buffer disappearance)

[Hrvoje Niksic]

<jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

> | 1998-10-21 Hrvoje Niksic <hniksic@srce.hr> list.ding
> | 
> | ...the cleanup code that evaluates no matter what way we exit from the
> | function -- including C-g. This is exactly what unwind-protect is for.
> 
> This was something I wondered an hour ago in my own code. What
> does "nonlocal" exist mean?

Nonlocal exit means an exit via signal or throw.  In the ``C''
terminology, it's longjmp.

> And is it corect that cleanup is not done if debug is on?

Cleanup is done either way.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
If it's tourist season, why can't we shoot them?

Feature req: import/export Group parameter or Server data

[Jari Aalto+list.ding]

    I'd like to see a function that steps through all Groups and
    Topics and which would dump the Group parameter (And server)
    data in so that I could save that periodically to
    separate backup disk.

    So if my .newsrc* is sometimes gone or if I killed some groups
    by accident, I could cut'n paste or Import the Group Parameter
    back to the group

    So a simple Write/Read Group parameter data to a file would
    be fine for now. A Map-through-groups toplevel function would
    be next step.

    I also move data between several Emasc/Gnus in different sites, so
    exporting, importing Group/Server data would be nice.

    jari

    

Re: Feature req: import/export Group parameter or Server data

[Simon Josefsson]

<jari.aalto@poboxes.com> (Jari Aalto+list.ding) writes:

>     So a simple Write/Read Group parameter data to a file would
>     be fine for now. A Map-through-groups toplevel function would
>     be next step.
> 
>     I also move data between several Emasc/Gnus in different sites, so
>     exporting, importing Group/Server data would be nice.

I think a cleaner way to keep several Gnus configurations synchronized
(it seems as this is the problem you're trying to solve) would be to
use ACAP. This wouldn't synchronize localy stored mail of course, but
you could use IMAP instead.

http://andrew2.andrew.cmu.edu/cyrus/acap/

The ACAP protocol is much like the IMAP protocol, most of the code can
be shared between them.