HEADS UP: Largely rewritten gnus-agent implementation.

HEADS UP: Largely rewritten gnus-agent implementation.

[Kai Großjohann]

Kevin Greiner did a really great job, I think, of improving
gnus-agent and making it more efficient, too.  I kind of forgot what
exactly he has changed, but I can say the following:

* The old .fetched files that I introduced are not needed anymore.

* gnus-agent-consider-all-articles is supported properly.

There is a sanity check in there which invokes (debug), so if you see
that, please report it to Kevin and/or me, with some information
about what you were seeing.  After gathering the data (especially the
contents of the backtrace buffer), it should be safe to just
continue, the mess will be cleaned up automatically.

The ChangeLog entries are from me, they are probably bogus to some
degree.  This can be sorted out later, though.

Kevin is gone over the weekend and he suggested that I wait with
committing this, but I'm too excited to wait!

Ah, maybe I should mention some gotcha.  With previous versions of the
code (but not the one I'm checking in!) I saw that articles were marked
as read when entering the group and they appeared to be gone.  If this
happens, don't panik.  Instead, do C-x u from the group buffer
(gnus-undo, to revert the marking as read), then use `J u' on the
group to fetch it, then try to enter the group again.  This worked
reliably to make the articles reappear when I tried it.  (The problem
only happens in plugged mode.)  I don't think that you will see this,
but just in case...

I think that's it!  Please report your findings.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: HEADS UP: Largely rewritten gnus-agent implementation.

[Danny Siu]

I am only using nnnil as primary and nnimap as secondary backend.  I removed
all .fetched files, did a 'gnus-agent-regenerate', and 'J s'

- gnus-agent-regenerate seems to do the right finally: it recreates
  .agentview based on articles that have already been download on disk. This
  alone saved me hours of agent refetching time!  Thanks for making this
  works.

- i have (setq gnus-agent-mark-unread-after-downloaded nil) but sometimes
  articles are marked read ('O') after being splitted to the its destination
  group.

- .agentview files may contain bogus info, like "nil 2" etc.  (or it has a
  new format now?)

- i am seeing all my dormanted articles became read (marked 'O')!!!  I know
  that nnimap stores gnus specific marks, like dormant, on IMAP servers that
  support custom marks.  this is a major problem for agent right now.

agent is working much better than before and i am seeing some operations are
much faster too.  

thanks for the good work, Kevin and Kai!

Kai Großjohann writes:

  Kai> Kevin Greiner did a really great job, I think, of improving
  Kai> gnus-agent and making it more efficient, too.  I kind of forgot what
  Kai> exactly he has changed, but I can say the following:

  Kai> * The old .fetched files that I introduced are not needed anymore.

  Kai> * gnus-agent-consider-all-articles is supported properly.

  Kai> There is a sanity check in there which invokes (debug), so if you see
  Kai> that, please report it to Kevin and/or me, with some information
  Kai> about what you were seeing.  After gathering the data (especially the
  Kai> contents of the backtrace buffer), it should be safe to just
  Kai> continue, the mess will be cleaned up automatically.

  Kai> The ChangeLog entries are from me, they are probably bogus to some
  Kai> degree.  This can be sorted out later, though.

  Kai> Kevin is gone over the weekend and he suggested that I wait with
  Kai> committing this, but I'm too excited to wait!

  Kai> Ah, maybe I should mention some gotcha.  With previous versions of
  Kai> the code (but not the one I'm checking in!) I saw that articles were
  Kai> marked as read when entering the group and they appeared to be gone.
  Kai> If this happens, don't panik.  Instead, do C-x u from the group
  Kai> buffer (gnus-undo, to revert the marking as read), then use `J u' on
  Kai> the group to fetch it, then try to enter the group again.  This
  Kai> worked reliably to make the articles reappear when I tried it.  (The
  Kai> problem only happens in plugged mode.)  I don't think that you will
  Kai> see this, but just in case...

  Kai> I think that's it!  Please report your findings.

  Kai> kai -- ~/.signature is: umop ap!sdn (Frank Nobis)


-- 
Danny Siu

Re: HEADS UP: Largely rewritten gnus-agent implementation.

[Danny Siu]

oops. forgot to mention that the new gnus-agent-downloaded-article-face
(orange/yellow) is getting too much attention than the unread ones.  it is
okey for unplugged mode but when plugged, people probably don't care if the
articles is downloaded or not.  even when they do, a "+"/"-" on the summary
line would be enough.

i guess i can customize gnus-summary-highlight to use
gnus-agent-downloaded-article-face only when unplugged.

Kai Großjohann writes:

  Kai> Kevin Greiner did a really great job, I think, of improving
  Kai> gnus-agent and making it more efficient, too.  I kind of forgot what
  Kai> exactly he has changed, but I can say the following:

  Kai> * The old .fetched files that I introduced are not needed anymore.

  Kai> * gnus-agent-consider-all-articles is supported properly.

  Kai> There is a sanity check in there which invokes (debug), so if you see
  Kai> that, please report it to Kevin and/or me, with some information
  Kai> about what you were seeing.  After gathering the data (especially the
  Kai> contents of the backtrace buffer), it should be safe to just
  Kai> continue, the mess will be cleaned up automatically.

  Kai> The ChangeLog entries are from me, they are probably bogus to some
  Kai> degree.  This can be sorted out later, though.

  Kai> Kevin is gone over the weekend and he suggested that I wait with
  Kai> committing this, but I'm too excited to wait!

  Kai> Ah, maybe I should mention some gotcha.  With previous versions of
  Kai> the code (but not the one I'm checking in!) I saw that articles were
  Kai> marked as read when entering the group and they appeared to be gone.
  Kai> If this happens, don't panik.  Instead, do C-x u from the group
  Kai> buffer (gnus-undo, to revert the marking as read), then use `J u' on
  Kai> the group to fetch it, then try to enter the group again.  This
  Kai> worked reliably to make the articles reappear when I tried it.  (The
  Kai> problem only happens in plugged mode.)  I don't think that you will
  Kai> see this, but just in case...

  Kai> I think that's it!  Please report your findings.

  Kai> kai -- ~/.signature is: umop ap!sdn (Frank Nobis)


-- 
Danny Siu

Re: HEADS UP: Largely rewritten gnus-agent implementation.

[Kai Großjohann]

Danny Siu <dsiu@adobe.com> writes:

> I am only using nnnil as primary and nnimap as secondary backend.  I
> removed all .fetched files, did a 'gnus-agent-regenerate', and 'J s'
>
> - gnus-agent-regenerate seems to do the right finally: it recreates
>   .agentview based on articles that have already been download on disk. This
>   alone saved me hours of agent refetching time!  Thanks for making this
>   works.

Yes, thanks a lot, Kevin.

> - i have (setq gnus-agent-mark-unread-after-downloaded nil) but sometimes
>   articles are marked read ('O') after being splitted to the its destination
>   group.

I don't notice this.  I use splitting with nnimap and I have the same
setting, but split articles are not marked as read.

I have seen mark-as-read when entering a group, but I fixed that as I
described.

> - .agentview files may contain bogus info, like "nil 2" etc.  (or it has a
>   new format now?)

nil means it's empty, 2 means it's in format 2.  Yes, Kevin has
introduced a new format.  The new format supports ranges and also
includes the history file information, so that the history file is
not needed anymore.

> - i am seeing all my dormanted articles became read (marked 'O')!!!  I know
>   that nnimap stores gnus specific marks, like dormant, on IMAP servers that
>   support custom marks.  this is a major problem for agent right now.

I use dormant articles rarely.  Let me test this with an nnimap group.

> thanks for the good work, Kevin and Kai!

My work consisted of writing the ChangeLog entry.  Kudos to Kevin,
not to me.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: HEADS UP: Largely rewritten gnus-agent implementation.

[Kai Großjohann]

Danny Siu <dsiu@adobe.com> writes:

> oops. forgot to mention that the new gnus-agent-downloaded-article-face
> (orange/yellow) is getting too much attention than the unread ones.

Yes.  I use this:

(set-face-bold-p 'gnus-agent-downloaded-article-face nil)
(set-face-foreground 'gnus-agent-downloaded-article-face "slateblue4")

What do people think?  Does it look okay on a tty?

> it is okey for unplugged mode but when plugged, people probably
> don't care if the articles is downloaded or not.  even when they do,
> a "+"/"-" on the summary line would be enough.

Hm.  Interesting point of view.  Never thought about this.  Opinions?

Also, something that crossed my mind is that it might be more useful
to highlight the undownloaded instead of the downloaded articles.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: HEADS UP: Largely rewritten gnus-agent implementation.

[Kai Großjohann]

Danny Siu <dsiu@adobe.com> writes:

> - i am seeing all my dormanted articles became read (marked 'O')!!!  I know
>   that nnimap stores gnus specific marks, like dormant, on IMAP servers that
>   support custom marks.  this is a major problem for agent right now.

Can you explain when it happens?  I remember that I had dormant
articles in some nnimap groups for a while.

I just marked a message (and old one where I kept hitting M-u on it
whenever I read it by mistake) as dormant (in an nnimap group).  What
do I have to do to see that it gets marked as read?  Fetch the
session?  Go unplugged?

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: HEADS UP: Largely rewritten gnus-agent implementation.

[Denis Yakovlev]

Before: gnus-summary-{next,prev}-unread-article skip undownloaded
articles.
Now: trying to select them.
Something goes wrong?
-- 
Denis K.Y.

Re: HEADS UP: Largely rewritten gnus-agent implementation.

[Mark Triggs]

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

> I think that's it!  Please report your findings.

I've just checked out the latest source from CVS, and can certainly see
the improvement (thanks Kevin :o), but have had a few slight hiccups..

Doing '/ o' in the summary buffer (gnus-summary-insert-old-articles) I
get the following error:


  Debugger entered--Lisp error: (void-function gnus-range-difference)

  gnus-range-difference(((1471 . 2560)) (1471 1472 1473 1474 1475 1476
  1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490
  1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504
  1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518
  1519 1520 ...))

  gnus-summary-insert-old-articles(nil)
  call-interactively(gnus-summary-insert-old-articles)
  recursive-edit()

  [snip byte-code]

  debug(error (void-function gnus-range-difference))

  gnus-range-difference(((1471 . 2560)) (1471 1472 1473 1474 1475 1476
  1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490
  1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504
  1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518
  1519 1520 ...))

  gnus-summary-insert-old-articles(nil)
  call-interactively(gnus-summary-insert-old-articles)


A grep of the source didn't turn up a defun for 'gnus-range-difference'
anywhere, but I do have a 'gnus-list-range-difference' (in
gnus-range.el).

Also, I'm entering the server buffer and agentizing my nntp server using
'J a', but I'm finding that when I save ~/.newsrc.eld and restart gnus,
the server is no longer agentized. I don't actually use the agent for
fetching articles, but I do use it for caching article headers. Can
anyone else reproduce this?

Thanks again. All the best,

Mark 

-- 
Mark Triggs
<mst@dishevelled.net>

Re: HEADS UP: Largely rewritten gnus-agent implementation.

[Kai Großjohann]

Mark Triggs <mst@dishevelled.net> writes:

> kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:
>
>> I think that's it!  Please report your findings.
>
> I've just checked out the latest source from CVS, and can certainly see
> the improvement (thanks Kevin :o), but have had a few slight hiccups..
>
> Doing '/ o' in the summary buffer (gnus-summary-insert-old-articles) I
> get the following error:
>
>
>   Debugger entered--Lisp error: (void-function gnus-range-difference)

Ick.

I will check in the following fix in a jiffy.  Does it work?

cvs server: Diffing .
cvs server: Diffing contrib
cvs server: Diffing etc
cvs server: Diffing etc/gnus
cvs server: Diffing etc/smilies
cvs server: Diffing lisp
Index: lisp/ChangeLog
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/ChangeLog,v
retrieving revision 6.1682
diff -u -r6.1682 ChangeLog
--- lisp/ChangeLog	2002/11/23 15:56:57	6.1682
+++ lisp/ChangeLog	2002/11/24 14:10:28
@@ -1,3 +1,9 @@
+2002-11-24  Kai Gro,A_(Bjohann  <kai.grossjohann@uni-duisburg.de>
+
+	* gnus-sum.el (gnus-summary-insert-old-articles): Use
+	gnus-remove-from-range instead of gnus-range-difference which
+	doesn't exist.
+
 2002-11-23  Kai Gro,A_(Bjohann  <kai.grossjohann@uni-duisburg.de>
 	From Kevin Greiner <kgreiner@xpediantsolutions.com>.
 
Index: lisp/gnus-sum.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gnus-sum.el,v
retrieving revision 6.239
diff -u -r6.239 gnus-sum.el
--- lisp/gnus-sum.el	2002/11/23 15:56:57	6.239
+++ lisp/gnus-sum.el	2002/11/24 14:10:50
@@ -11178,7 +11178,7 @@
 ;;;	      (gnus-sorted-difference
 ;;;	       (gnus-uncompress-range (list gnus-newsgroup-active))
 ;;;	       old)
-              (gnus-range-difference (list gnus-newsgroup-active) old)
+	      (gnus-remove-from-range (list gnus-newsgroup-active) old)
 )
 	(setq len (gnus-range-length older))
 	(cond
cvs server: Diffing texi
cvs server: Diffing texi/etc
cvs server: Diffing texi/herds
cvs server: Diffing texi/misc
cvs server: Diffing texi/picons
cvs server: Diffing texi/ps
cvs server: Diffing texi/screen
cvs server: Diffing texi/smilies
cvs server: Diffing texi/xface


kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: HEADS UP: Largely rewritten gnus-agent implementation.

[Mark Triggs]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:
> Ick.
>
> I will check in the following fix in a jiffy.  Does it work?

[...]

After applying the patch, I seem to get the following:

  Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p (4882 . 5694))
    gnus-sorted-difference(((4882 . 5694) (5698 . 5700)) (5695 5696 5697))
    gnus-summary-insert-articles(((4882 . 5694) (5698 . 5700)))
    gnus-summary-insert-old-articles(nil)
    call-interactively(gnus-summary-insert-old-articles)

Any thoughts?

Cheers,

Mark

-- 
Mark Triggs
<mst@dishevelled.net>

Re: HEADS UP: Largely rewritten gnus-agent implementation.

[Danny Siu]

Kai Großjohann writes:

  Kai> Yes.  I use this:

  Kai> (set-face-bold-p 'gnus-agent-downloaded-article-face nil)
  Kai> (set-face-foreground 'gnus-agent-downloaded-article-face
  Kai> "slateblue4")

much better now.  i use 'medium blue' for unseen article and the downloaded
articles now looks more like unread/unseen ones.

-- 
Danny Siu

Re: HEADS UP: Largely rewritten gnus-agent implementation.

[Danny Siu]

Kai Großjohann writes:

  Kai> Also, something that crossed my mind is that it might be more useful
  Kai> to highlight the undownloaded instead of the downloaded articles.

To me, yes, that is more useful since I have
'gnus-agent-fetch-selected-article in 'gnus-select-article-hook and hence
all of the articles I read would be downloaded.

-- 
Danny Siu

Re: HEADS UP: Largely rewritten gnus-agent implementation.

[Henrik Enberg]

Danny Siu <dsiu@adobe.com> writes:

> oops. forgot to mention that the new gnus-agent-downloaded-article-face
> (orange/yellow) is getting too much attention than the unread ones.  it is
> okey for unplugged mode but when plugged, people probably don't care if the
> articles is downloaded or not.  even when they do, a "+"/"-" on the summary
> line would be enough.
  
  I fully agree.  You lose the ability to show articles with high score
  in bold right now.  It would be much better to have it for
  undownloaded articles instead.

Re: HEADS UP: Largely rewritten gnus-agent implementation.

[Kai Großjohann]

Mark Triggs <mst@dishevelled.net> writes:

> After applying the patch, I seem to get the following:
>
>   Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p (4882 . 5694))
>     gnus-sorted-difference(((4882 . 5694) (5698 . 5700)) (5695 5696 5697))
>     gnus-summary-insert-articles(((4882 . 5694) (5698 . 5700)))
>     gnus-summary-insert-old-articles(nil)
>     call-interactively(gnus-summary-insert-old-articles)

Could you apply the following patch on top of the previous one?
I even tested it once :-)

--- gnus-sum.el	2002/11/21 07:43:41	6.238.1.1
+++ gnus-sum.el	2002/11/25 07:26:57
@@ -11178,7 +11178,8 @@
 ;;;	      (gnus-sorted-difference
 ;;;	       (gnus-uncompress-range (list gnus-newsgroup-active))
 ;;;	       old)
-              (gnus-range-difference (list gnus-newsgroup-active) old)
+	      (gnus-uncompress-range
+	       (gnus-remove-from-range (list gnus-newsgroup-active) old))
 )
 	(setq len (gnus-range-length older))
 	(cond

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: HEADS UP: Largely rewritten gnus-agent implementation.

[Mark Triggs]

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

> Could you apply the following patch on top of the previous one?
> I even tested it once :-)

Yep, this fixes it :o)

Thanks very much,

Mark


-- 
Mark Triggs
<mst@dishevelled.net>

Re: HEADS UP: Largely rewritten gnus-agent implementation.

[Kai Großjohann]

Mark Triggs <mst@dishevelled.net> writes:

> kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:
>
>> Could you apply the following patch on top of the previous one?
>> I even tested it once :-)
>
> Yep, this fixes it :o)

Committed.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: HEADS UP: Largely rewritten gnus-agent implementation.

[Kevin Greiner]

[-- Attachment #1.1: Type: text/plain, Size: 1839 bytes --]

Mark,
Thanks for the feedback.

Kai- You're right that gnus-remove-from-range is effectively the 
gnus-range-difference that I wrote.  I have found one critical 
difference; gnus-range-difference creates a new range rather than 
editing the original range1.  The gnus-summary-insert-old-articles 
function passes gnus-newsgroup-active so there is a chance that 
gnus-remove-from-range might corrupt the active range.  Calling 
gnus-remove-from-range would have otherwise worked except that I 
introduced a new bug with the rest of my changes.  I've attached a patch 
for gnus-sum.el (version 6.241) below that will get 
gnus-summary-insert-old-articles working with gnus-range-difference. 
 I've also attached a patch for adding gnus-range-difference to 
gnus-range.el (version 6.12).

Kevin

Kai Großjohann wrote:

>Mark Triggs <mst@dishevelled.net> writes:
>
>  
>
>>After applying the patch, I seem to get the following:
>>
>>  Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p (4882 . 5694))
>>    gnus-sorted-difference(((4882 . 5694) (5698 . 5700)) (5695 5696 5697))
>>    gnus-summary-insert-articles(((4882 . 5694) (5698 . 5700)))
>>    gnus-summary-insert-old-articles(nil)
>>    call-interactively(gnus-summary-insert-old-articles)
>>    
>>
>
>Could you apply the following patch on top of the previous one?
>I even tested it once :-)
>
>--- gnus-sum.el	2002/11/21 07:43:41	6.238.1.1
>+++ gnus-sum.el	2002/11/25 07:26:57
>@@ -11178,7 +11178,8 @@
> ;;;	      (gnus-sorted-difference
> ;;;	       (gnus-uncompress-range (list gnus-newsgroup-active))
> ;;;	       old)
>-              (gnus-range-difference (list gnus-newsgroup-active) old)
>+	      (gnus-uncompress-range
>+	       (gnus-remove-from-range (list gnus-newsgroup-active) old))
> )
> 	(setq len (gnus-range-length older))
> 	(cond
>
>kai
>  
>



[-- Attachment #1.2: Type: text/html, Size: 2270 bytes --]

[-- Attachment #2: patch-range.txt --]
[-- Type: text/plain, Size: 1705 bytes --]

diff -r6.12 gnus-range.el
63a64,104
> (defun gnus-range-difference (range1 range2)
>   "Return the range of elements in RANGE1 that do not appear in RANGE2.
> Both ranges must be in ascending order."
>   (setq range1 (gnus-range-normalize range1))
>   (setq range2 (gnus-range-normalize range2))
>   (let* ((new-range (cons nil (copy-sequence range1)))
>          (r new-range)
>          (safe t))
>     (while (cdr r)
>       (let* ((r1 (cadr r))
>              (r2 (car range2))
>              (min1 (if (numberp r1) r1 (car r1)))
>              (max1 (if (numberp r1) r1 (cdr r1)))
>              (min2 (if (numberp r2) r2 (car r2)))
>              (max2 (if (numberp r2) r2 (cdr r2))))
> 
>         (cond ((> min1 max1)
>                ;; Invalid range: may result from overlap condition (below)
>                ;; remove Invalid range
>                (setcdr r (cddr r)))
>               ((and (= min1 max1)
>                     (listp r1))
>                ;; Inefficient representation: may result from overlap condition (below)
>                (setcar (cdr r) min1))
>               ((not min2)
>                ;; All done with range2
>                (setq r nil))
>               ((< max1 min2)
>                ;; No overlap: range1 preceeds range2
>                (pop r))
>               ((< max2 min1)
>                ;; No overlap: range2 preceeds range1
>                (pop range2))
>               ((and (<= min2 min1) (<= max1 max2))
>                ;; Complete overlap: range1 removed
>                (setcdr r (cddr r)))
>               (t
>                (setcdr r (nconc (list (cons min1 (1- min2)) (cons (1+ max2) max1)) (cddr r)))))))
>     (cdr new-range))
>   )
> 

[-- Attachment #3: patch-sum.txt --]
[-- Type: text/plain, Size: 403 bytes --]

RCS file: /usr/local/cvsroot/gnus/lisp/gnus-sum.el,v
retrieving revision 6.241
diff -r6.241 gnus-sum.el
11181,11182c11181
< 	      (gnus-uncompress-range
< 	       (gnus-remove-from-range (list gnus-newsgroup-active) old))
---
>               (gnus-range-difference (list gnus-newsgroup-active) old)
11202c11201,11202
< 	 (all nil)
---
> 	 (all 
>           (setq older (gnus-uncompress-range older)))

Re: HEADS UP: Largely rewritten gnus-agent implementation.

[Henrik Enberg]

Henrik Enberg <henrik@enberg.org> writes:

> Danny Siu <dsiu@adobe.com> writes:
>
>> oops. forgot to mention that the new gnus-agent-downloaded-article-face
>> (orange/yellow) is getting too much attention than the unread ones.
>
> I fully agree.  You lose the ability to show articles with high score
> in bold right now.  It would be much better to have it for
> undownloaded articles instead.

  FWIW, if anyone else is as annoyed by this as I am, here's what I did
  to get rid of it completely.

  (eval-after-load "gnus-sum"
    '(delete '(downloaded . gnus-agent-downloaded-article-face)
	     gnus-summary-highlight))

Re: HEADS UP: Largely rewritten gnus-agent implementation.

[Kai Großjohann]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> Kai- You're right that gnus-remove-from-range is effectively the
> gnus-range-difference that I wrote.

Eek.  My bad, I completely missed that function before.

Commit is in progress.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: HEADS UP: Largely rewritten gnus-agent implementation.

[Kai Großjohann]

Henrik Enberg <henrik@enberg.org> writes:

>   I fully agree.  You lose the ability to show articles with high score
>   in bold right now.  It would be much better to have it for
>   undownloaded articles instead.

Kevin,

what do you think about replacing

 (downloaded . gnus-agent-downloaded-article-face)

with

 ((and gnus-agent-mode (not downloaded)) 
  . gnus-agent-undownloaded-article-face)

with a new face?

(I haven't tried the above entry, I'm not sure if it will work.)

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: HEADS UP: Largely rewritten gnus-agent implementation.

[Kevin Greiner]

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



Kai Großjohann wrote:

>Henrik Enberg <henrik@enberg.org> writes:
>
>  
>
>>  I fully agree.  You lose the ability to show articles with high score
>>  in bold right now.  It would be much better to have it for
>>  undownloaded articles instead.
>>    
>>
>
>Kevin,
>
>what do you think about replacing
>
> (downloaded . gnus-agent-downloaded-article-face)
>
>with
>
> ((and gnus-agent-mode (not downloaded)) 
>  . gnus-agent-undownloaded-article-face)
>
>with a new face?
>
>(I haven't tried the above entry, I'm not sure if it will work.)
>
>kai
>  
>
I have to admit, my first thought was absolutely not. I use the agent to 
selectively agentize threads so must of my group buffer would be that 
annoying orange that I set for the default.  I also felt that it was 
inappropriate to perform an action based on the lack of an attribute. 
 However, after thinking about it, I can see where the undownloaded face 
could be taken as a per-article warning (i.e. download this article 
before going unplugged).

We'll need a better color choice.  Any suggestions?


Kevin





[-- Attachment #2: Type: text/html, Size: 1585 bytes --]

Re: HEADS UP: Largely rewritten gnus-agent implementation.

[Kevin Greiner]

Denis Yakovlev wrote:

>Before: gnus-summary-{next,prev}-unread-article skip undownloaded
>articles.
>Now: trying to select them.
>Something goes wrong?
>  
>
Ouch.  I had a problem with the undownloaded mark being misinterpreted 
as a read mark so I disabled that mark.  It looks like I'll have to 
figure out another solution.

In the meantime, take a look at gnus-article-mark in gnus-sum.el. 
Uncomment the gnus-undownloaded-mark line to fix your problem.

Kevin

Re: HEADS UP: Largely rewritten gnus-agent implementation.

[Kai Großjohann]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> I have to admit, my first thought was absolutely not. I use the agent
> to selectively agentize threads so must of my group buffer would be
> that annoying orange that I set for the default.  I also felt that it
> was inappropriate to perform an action based on the lack of an
> attribute. However, after thinking about it, I can see where the
> undownloaded face could be taken as a per-article warning
> (i.e. download this article before going unplugged).
>
> We'll need a better color choice.  Any suggestions?

Yes, I think the general idea in this discussion is to use a
`subdued' face, instead of an attention-getting face.

I've tried different fg colors, including mediumseagreen, slateblue4
and firebrick, and now I'm using saddlebrown.  But I haven't inverted
the meaning of the face, yet.  Maybe after inversion, some greyish
color might be suitable?

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)