gnus-cache redux

gnus-cache redux

[Lars Magne Ingebrigtsen]

Or whatever.

Anyways, I've added an active file to gnus-cache, which means that
Gnus startup with the cache won't be noticably slower than starting
Gnus without the cache.

While I'm revising gnus-cache, I wonder whether I should do more.  I'm
not really satisfied with the method Gnus uses for entering/removing
stuff from the cache -- it's all based on the article marks, and it
feels a bit kludgy.  I'm also wondering how to fit that "persistent
article" thingie into the scheme.

I'm open to ideas.  If you've given gnus-cache some thought, speak now
or forever hold your tongue.  (Ick!)

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

Re: gnus-cache redux

[Sudish Joseph]

Lars Magne Ingebrigtsen writes:
> While I'm revising gnus-cache, I wonder whether I should do more.  I'm
> not really satisfied with the method Gnus uses for entering/removing
> stuff from the cache -- it's all based on the article marks, and it
> feels a bit kludgy.  I'm also wondering how to fit that "persistent
> article" thingie into the scheme.

> I'm open to ideas.  If you've given gnus-cache some thought, speak now
> or forever hold your tongue.  (Ick!)

I had, back in the 90's (sounds cool that way :-).  I think I mailed
you some suggestions which I no longer have a copy of.  

All I remember is that the cache should be dissociated with ticking.
Essentially, I'd prefer the cache to be a better way of doing what I
currently do using gnus-summary-copy-article.  I.e., articles in the
cache should have their own enter-cache/delete-from-cache commands,
and their own mark.  Ticked articles would be entirely separate.  I
often tick articles that I plan to reply to later, while  I use
gnus-summary-copy-article when I wish to retain the article for longer
periods.  Having one interface to both is kludgy, IMO, and is the only
reason I stopped using the cache.  (Disk quotas prevent me from
ticking as much as I'd like if I use the cache.)

I don't know what the "persistent articles" refered to above are, but
they too should probably be kept away from the tick/untick interface
if they involve making a local copy.

-Sudish

gnus-cache redux

[Luis Fernandes]

I would like to propose some tools for managing caches. 

		- I'm finding that I cache a lot of articles for future
		  reference but tend to forget what group the article was in.

		- I cannot search (by keyword/regexp) the cache for articles

A "cache group-buffer" that gathers all the cached articles, might
help...

Re: gnus-cache redux

[Felix Lee]

> I'm open to ideas.  If you've given gnus-cache some thought, speak now
> or forever hold your tongue.  (Ick!)

lessee..  I was wondering if caching could be murgled with async news
fetching.  but this is better handled with a separate process since
emacs doesn't have strong async support.
--

Re: gnus-cache redux

[Lars Magne Ingebrigtsen]

Sudish Joseph <joseph@cis.ohio-state.edu> writes:

> All I remember is that the cache should be dissociated with ticking.
> Essentially, I'd prefer the cache to be a better way of doing what I
> currently do using gnus-summary-copy-article.

Yes, that's what was meant by "persistent article" -- you tap some
key, and the article will forever remain in the group, untouched by
the server expiry process.  (I.e., it's put in the cache.)

I agree with you that caching should be dissociated from the marks.
I'm currently leaning towards just adding two enter/exit commands, and
an "*" would be displayed in the second column of the screen (where
"#" and "A" are displayed.  A bit crowded, perhaps.  :-)  

So caching would be totally disconnected from the readedness marks.  

... hey, the `*' key is free!  Miracles of miracles... `*' to enter an
article into the cache and `M-*' to remove it?  

This would be in addition to the current way of doing things, of
course. 

-- 
Home is where the cat is.

Re: gnus-cache redux

[Lars Magne Ingebrigtsen]

elf@mailhost.ee.ryerson.ca (Luis Fernandes) writes:

> I would like to propose some tools for managing caches. 
> 
> 		- I'm finding that I cache a lot of articles for future
> 		  reference but tend to forget what group the article was in.
> 
> 		- I cannot search (by keyword/regexp) the cache for articles
> 
> A "cache group-buffer" that gathers all the cached articles, might
> help...

Hm.  That's quite interesting.  If you have lots of articles spread in
lots of different directories, there should be a way to do useful
things on the directory hierarchy as a whole...  

I see no self-evident way of doing stuff like that, though.
nnhierarchy, anyone?  Or...  uhm.  No, I'm drawing blanks here.  Do we
need something brand new?  

-- 
Home is where the cat is.

Re: gnus-cache redux

[Scott Blachowicz]

larsi@ifi.uio.no (Lars Magne Ingebrigtsen) wrote:

> I agree with you that caching should be dissociated from the marks.
> I'm currently leaning towards just adding two enter/exit commands, and
> an "*" would be displayed in the second column of the screen (where
> "#" and "A" are displayed.  A bit crowded, perhaps.  :-)  

Which reminds me...how does one specify highlighting on the process-mark?
I've got this (which doesn't work - presumably 'mark is bound to whatever
is in the first column):

    (cond
     ((eq gnus-display-type 'color)
      (setq gnus-summary-highlight
            (list
             (cons '(= mark gnus-process-mark)
                   (custom-face-lookup nil "gold" nil nil nil nil))
             (cons '(= mark gnus-canceled-mark)
                   (custom-face-lookup "red" "black" nil nil nil nil))
             ;;...etc...

Also, is it possible to combine highlighting attributes?  For example,
change the foreground color based on process-mark and background based on
other marks?  Or do I have to enumerate all the combinations myself?

Thanx,
Scott Blachowicz    Ph: 206/283-8802x240    StatSci, a div of MathSoft, Inc.
                                            1700 Westlake Ave N #500
scott@statsci.com                           Seattle, WA USA   98109
Scott.Blachowicz@seaslug.org

Re: gnus-cache redux

[Lars Magne Ingebrigtsen]

Scott Blachowicz <scott@statsci.com> writes:

> Which reminds me...how does one specify highlighting on the process-mark?

(cons '(memq (gnus-summary-article-number) gnus-newsgroup-processable)
       (custom-face-lookup nil "gold" nil nil nil nil))

Or something like that.  September 0.22 will bind `article' so you
avoid doing that `(gnus-summary-article-number)' thing...

> Also, is it possible to combine highlighting attributes?  For example,
> change the foreground color based on process-mark and background based on
> other marks?  Or do I have to enumerate all the combinations myself?

I think you have to, but perhaps you shouldn't have to?  I have no
idea how to implement something that would make combining highlight
attributes possible, though...

-- 
Home is where the cat is.

Re: gnus-cache redux

[Scott Blachowicz]

larsi@ifi.uio.no (Lars Magne Ingebrigtsen) wrote:

> > Which reminds me...how does one specify highlighting on the process-mark?
> 
> (cons '(memq (gnus-summary-article-number) gnus-newsgroup-processable)
>        (custom-face-lookup nil "gold" nil nil nil nil))
> 
> Or something like that.  September 0.22 will bind `article' so you
> avoid doing that `(gnus-summary-article-number)' thing...

That doesn't quite work...after I make that change (in v5.1, I think), I
enter a group and hit `#' to process-mark a message - no highlighting
change.  Then, I go back to the message and get it with `g' - now I get
the highlighting.  Is the message on in gnus-newsgroup-processable at the
point that the highlighting occurs?  Or something like that?

Scott Blachowicz    Ph: 206/283-8802x240    StatSci, a div of MathSoft, Inc.
                                            1700 Westlake Ave N #500
scott@statsci.com                           Seattle, WA USA   98109
Scott.Blachowicz@seaslug.org

Re: gnus-cache redux

[Kai Grossjohann]

>>>>> On 07 Dec 1995 11:48:03 +0100, Lars Magne Ingebrigtsen
<larsi@ifi.uio.no> said: 

  Lars> Or whatever.  Anyways, I've added an active file to
  Lars> gnus-cache, which means that Gnus startup with the cache won't
  Lars> be noticably slower than starting Gnus without the cache.

  Lars> While I'm revising gnus-cache, I wonder whether I should do
  Lars> more.  I'm not really satisfied with the method Gnus uses for
  Lars> entering/removing stuff from the cache -- it's all based on
  Lars> the article marks, and it feels a bit kludgy.  I'm also
  Lars> wondering how to fit that "persistent article" thingie into
  Lars> the scheme.

When I `*' an article to put it in the cache, will it always appear in
the group listing like a `!' article does, or won't it appear, like a
`?' article?  Or will this be configurable?  Or do we have two kinds
of `*', visible and invisible ones?

        \kai{}
--
Sometimes you lose; sometimes you just don't win.

Re: gnus-cache redux

[Lars Magne Ingebrigtsen]

Kai Grossjohann <grossjoh@dusty.informatik.uni-dortmund.de> writes:

> When I `*' an article to put it in the cache, will it always appear in
> the group listing like a `!' article does, or won't it appear, like a
> `?' article?  Or will this be configurable?  Or do we have two kinds
> of `*', visible and invisible ones?

Caching (with `*') is totally orthogonal to the readedness state of an
article.  So cached articles behave just like all other articles.

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

Re: gnus-cache redux

[Lars Magne Ingebrigtsen]

Scott Blachowicz <scott@statsci.com> writes:

> > (cons '(memq (gnus-summary-article-number) gnus-newsgroup-processable)
> >        (custom-face-lookup nil "gold" nil nil nil nil))
> 
> That doesn't quite work...after I make that change (in v5.1, I think), I
> enter a group and hit `#' to process-mark a message - no highlighting
> change.  Then, I go back to the message and get it with `g' - now I get
> the highlighting.  Is the message on in gnus-newsgroup-processable at the
> point that the highlighting occurs?  Or something like that?

The problem was that the function that changed the secondary mark
didn't call the function that did the visual updating.  This should
work better in September 0.22.

-- 
Home is where the cat is.