Those groups levels again

Those groups levels again

[Lars Magne Ingebrigtsen]

I just can't decide what to do about those pesky group levels.  This
is what I'm currently thinking about:

1) The level can be in integer, like now, between 1 and 9 (by default)

2) The level can be a cons, where the car has the level and the cdr
has a, uhm, score.  Perhaps.

Now, if we had this, we could do some interesting things.  Like
`sort-by-level-and-then-score'.  Then all level 4 groups would come
before all level 5 groups (so that those really important groups comes
before those less important) but we could still have bubbling on the
"score" of the group -- inside each level.  So whenever I read a level
5 group, the score would rise, and the next time I sort, that group
would "rise".  But it would never "rise" above any level 4 groups.

One could also do display-oriented things based on this (perhaps in
conjuction with `gnus-topic'.  Each level gets its own topic, and so
on. 

This would all be totally backwards compatible, and it's rather easy
to implement.  And it doesn't bloat the .newsrc.eld file much.  (I
originally thought of floating point levels, but that would really
either massively bloat the .newsrc.eld file, or slow down .newsrc.eld
generation dramatically.  (We couldn't use just `prin1' as now.))

Whadda y'all think?

In other news, I've been fixing lots & lots & lost of September bugs,
so I think that might be heading towards being usable.  nnsoup also
seems to have started behaving after I slapped it about a bit.  So I
think I'll be documenting it now.

Expect a release tomorrow.

-- 
Home is where the cat is.

Re: Those groups levels again

[Stainless Steel Rat]

X-Geek-3: GAT d-(++)@ s: a-
	C+(++) US++++$ P++>+++ L>+++ E+++ W++ N+++ K++++ w---$ O?>++ M-$ V-
	PS+ PE Y+(++) PGP++ !t 5++ X? R(+) tv b+++ DI+ D++ G+ e+>++(*) h! r y+
References: <w8s91lkwktz.fsf@surt.ifi.uio.no>

-----BEGIN PGP SIGNED MESSAGE-----

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

LMI> 2) The level can be a cons, where the car has the level and the cdr
LMI> has a, uhm, score.  Perhaps.

Do newsgroups really need to be scored? Resorting newsgroups isn't
something done too often, and it's generally easier to kill-yank groups
to put them where they belong than to score-score-score-score-resort...
DAMN! score-score-resort.... It's one thing to have subjects
automatically scored but implementing all the things that make scoring
useful in the summary buffer for the newsgroup buffer just seems like
useless overkill when you've already implemented levels.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMKehfJ6VRH7BJMxHAQFPhwP+PguWp2X+qMdlgAKBfhsgHRHpOnNHVme6
E9OgqPVtqZKmEITTzUeJGTmg65IfNpt1vLDsz66geZF2ujpp2S4MG0jazeWhESoD
Cd5wo7Xv0S0AFAS1F5AP7LN3ucHurlj6erUlMHu0kEb0rWdhWrCZp0s4jzEVcgFF
HjC9ktiSxzY=
=a2/I
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@ccs.neu.edu>          \ Ingredients of Happy Fun Ball include an
PGP Public Key: Ask for one today!  \ unknown glowing substance which fell to
http://www.ccs.neu.edu/home/ratinox/ \ Earth, presumably from outer space.

Re: Those groups levels again

[Felix Lee]

> Do newsgroups really need to be scored? Resorting newsgroups isn't

yes.  before I got stuck here on the end of a ppp link, I was
subscribed to several hundred newsgroups.  a couple dozen of them were
must-read.  the rest varied, depending on whatever.  (eg, I tended to
spend a few weeks with a tasty group found by jump-to-random-group.)

once in a while, I'd try to rearrange the list so that
currently-interesting groups were near the top, but this was always
cumbersome and harder to do than I liked, even when I had keys bound
to pushing groups up and down in the list.

what I think I really want is a spatialized newsgroup list, so I can
have a cluster of spandex-and-rhino-related newsgroups in one corner,
the anti-C++ brigade over there, the when-I-need-a-non-sequitur smear
in the back.

anyway.  yah, '(level . score) sounds okay.  (except for the level
part :) I'd be happy if levels disappared, in favor of something else.
like, umm, dunno.  something more like topics.  mmm.  I think I'd like
to have multiple group buffers.
--

Re: Those groups levels again

[Lars Magne Ingebrigtsen]

Stainless Steel Rat <ratinox@ccs.neu.edu> writes:

> Do newsgroups really need to be scored? Resorting newsgroups isn't
> something done too often, and it's generally easier to kill-yank groups
> to put them where they belong than to score-score-score-score-resort...
> DAMN! score-score-resort.... It's one thing to have subjects
> automatically scored but implementing all the things that make scoring
> useful in the summary buffer for the newsgroup buffer just seems like
> useless overkill when you've already implemented levels.

Too late!  I've already written the code for this!  Bwahahaha!  :-)

But really, I think it can be useful.  There's so much functionality
tied to the levels that doing more with them than we currently do
isn't advisable.  What I wanted was to implement "group bubbling",
which means that every time you enter a group, it goes "up".  (Several
people have requested this.)  While going "up", the general feeling
was that there should be several categories, so that one can guarantee
that the groups stay (generally) where they belong, but they should
"rise" in that subcategory.

And that is possible by combining levels and scores.  (New Gnuspeak
word -- "rank".  The rank of a group is defined as a combination of
the level and the score.)

I have written no commands for manually changing the score of groups.
I don't really plan to... unless there's a Violent Uprising Craving
Group Score Commands of '96!

-- 
Home is where the cat is.

Re: Those groups levels again

[Scott Blachowicz]

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

> And that is possible by combining levels and scores.  (New Gnuspeak
> word -- "rank".  The rank of a group is defined as a combination of
> the level and the score.)

Perhaps a revised glossary of the terms "level", "score" and "rank" as
they apply to Group buffers is in order?

My original thought was that "level" in this context refers to the
accessibility of the server for that group because it is used to decide
whether or not the initial Group buffer queries the server for number of
unread messages on that group.

I think of "score" as being a measure of my current interest in the
contents of the item being scored.  It seems (to me) to be orthogonal to
the concept of "level" in the group buffer.  It also seems (to me) to be
very similar to the concept of scoring in the summary buffer - it just
uses different attributes of the items being scored to decide on the
score.  Having the "score" of the group rise as a function of the number
of entries into that group strikes me as very close conceptually to
adaptive scoring in the summary buffers.

And threads in summary buffers seem very close to "topics" in group
buffers...has anyone written that hierarchical object browser mode for
emacs yet?  Just subclass off of that for a group buffer or for a summary
buffer and away you go...:-))

> I have written no commands for manually changing the score of groups.
> I don't really plan to... unless there's a Violent Uprising Craving
> Group Score Commands of '96!

Take cover!!!! :-)

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: Those groups levels again

[Stainless Steel Rat]

X-Geek-3: GAT d-(++)@ s: a-
	C+(++) US++++$ P++>+++ L>+++ E+++ W++ N+++ K++++ w---$ O?>++ M-$ V-
	PS+ PE Y+(++) PGP++ !t 5++ X? R(+) tv b+++ DI+ D++ G+ e+>++(*) h! r y+
References: <w8s91lkwktz.fsf@surt.ifi.uio.no>
	<199511131950.OAA09268@delphi.ccs.neu.edu>
	<w8sbuqgqgfx.fsf@gymir.ifi.uio.no>

-----BEGIN PGP SIGNED MESSAGE-----

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

LMI> And that is possible by combining levels and scores. (New Gnuspeak
LMI> word -- "rank". The rank of a group is defined as a combination of
LMI> the level and the score.)

So, if bubbling is turned on, each time you enter a group it's rank
rises within that level and it's order in the list will change if the
new rank is higher than the other groups in the "block", right?

How do you go about having this work for some groups (such as
comp.unix.*) but not others (rec.arts.*)? If this is handled by levels
then I need to allocate two levels for each block of groups, one for the
groups that bubble and one for those that don't. With 7 useable levels
that doesn't leave much room to work with. Or I could come up with yet
another hideously ugly regexp for groups that do or don't bubble....

This is the kind of increased complexity and size I'm talking about.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMKfRZZ6VRH7BJMxHAQF60AQAqISabsPKFivgTNco3aquF1naXK1bgTZ1
7ivvm2qKSz0+CHoVQvnRi9g3Wn7isxQtMRW/t8TETHBVdQXNhj9mNlvULGLMDd0z
52yCsjYfgWNjrcf5PqxbnpkzuTTxN1lr7FoXupcnQeyi2bdJyTKgD6uz5s2nYwOl
ndbXcn84SQI=
=CP5f
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@ccs.neu.edu>          \ Warning: pregnant women, the elderly, and
PGP Public Key: Ask for one today!  \ children under 10 should avoid prolonged
http://www.ccs.neu.edu/home/ratinox/ \ exposure to Happy Fun Ball.

Re: Those groups levels again

[Lars Magne Ingebrigtsen]

Stainless Steel Rat <ratinox@ccs.neu.edu> writes:

> So, if bubbling is turned on, each time you enter a group it's rank
> rises within that level and it's order in the list will change if the
> new rank is higher than the other groups in the "block", right?

The score rises, but a group on level x will always have a higher rank
than a group on level x+1, no matter what the score is.

> How do you go about having this work for some groups (such as
> comp.unix.*) but not others (rec.arts.*)? If this is handled by levels
> then I need to allocate two levels for each block of groups, one for the
> groups that bubble and one for those that don't. With 7 useable levels
> that doesn't leave much room to work with. Or I could come up with yet
> another hideously ugly regexp for groups that do or don't bubble....

Well...  I'd imagine most people would either want bubbling -- or they
don't want bubbling.  Hideously ugly regexps and/or group parameters
can be used to fine-tune this, perhaps.  Or perhaps people can write
their own sorting functions.  (Bubbling is done simply by sorting the
groups over the ranks of the groups.  Other "bubbly" sorting schemes
is possible.  Or one could forego sorting altogether and do "local"
(aka. "real" bubbling).)

> This is the kind of increased complexity and size I'm talking about.

I think it nice having a program that is sufficiently complex that
nobody will ever learn all parts of it.  :-)  

-- 
Home is where the cat is.

Re: Those groups levels again

[Lars Magne Ingebrigtsen]

Manoj Srivastava <srivasta@pilgrim.umass.edu> writes:

> 	a) How does one reorder the topics in the buffer?

Good question.  I don't think you can.  I've added it to the todo
list.  Perhaps changing the order in `gnus-group-topics' will help,
although that's not documented.  And may not work.

> 	b) are topics hierarchical?

Not currently, but it's on the todo list.

>          I would like to have two top level topics called, say, by
> level, and by subject, and by turning the unique thing off, have
> each group belong to two places under the hierarchy, so I may peruse
> news in a sequence as the mood takes me. possible?

Yes, that sounds like a good idea, and I think it will be possible. 

-- 
Home is where the cat is.

Re: Those groups levels again

[Jack Vinson]

>>>>> "MS" == Manoj Srivastava <srivasta@pilgrim.umass.edu> writes:

MS> 	a) How does one reorder the topics in the buffer?

Topics appear only to be ordered by the order in which you have them
defined in the variable gnus-group-topics.  The first topic in the list
will be first in the Group buffer, etc.  This puts the "Misc" topic always
last.

-- 
Jack Vinson                                                  Sunderland, MA
jvinson@cheux.ecs.umass.edu    <http://www.cis.upenn.edu/~vinson/home.html>

Re: Those groups levels again

[Joe Hildebrand]

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

   Lars> I just can't decide what to do about those pesky group
   Lars> levels.  This is what I'm currently thinking about:

   Lars> 1) The level can be in integer, like now, between 1 and 9 (by
   Lars> default)

   Lars> 2) The level can be a cons, where the car has the level and
   Lars> the cdr has a, uhm, score.  Perhaps.

couldn't you just add another group parameter for score?


-- 
Joe Hildebrand                  Fuentez Systems Concepts
hildjj@fuentez.com              11781 Lee-Jackson Hwy, Suite 700
Lead Software Engineer          Fairfax, VA 22033
	"Breakfast recapitulates phylogeny" - Spider Robinson

Re: Those groups levels again

[Janne Sinkkonen]

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

    Lars> 1) The level can be in integer, like now, between 1 and 9
    Lars> (by default)

    Lars> 2) The level can be a cons, where the car has the level and
    Lars> the cdr has a, uhm, score.  Perhaps.

Levels are useful, but there's still too much those groups. I would
like to see a hierarchical group buffer. If that's too far out, topics
would be a good substitute. By topic I mean, I could say "I want the
comp groups", and then I get comp groups plus some general stuff like
mail groups, and other things like photography groups vanish
temporarily out of sight. I don't know what you mean by topics, though.

Scoring would maybe also help.

--
Janne

Re: Those groups levels again

[Lars Magne Ingebrigtsen]

Janne Sinkkonen <janne@avocado.pc.helsinki.fi> writes:

> Levels are useful, but there's still too much those groups. I would
> like to see a hierarchical group buffer. If that's too far out, topics
> would be a good substitute. By topic I mean, I could say "I want the
> comp groups", and then I get comp groups plus some general stuff like
> mail groups, and other things like photography groups vanish
> temporarily out of sight. I don't know what you mean by topics, though.

That's what I mean by topics, too.  :-)  It's included in September
Gnus.  

-- 
Home is where the cat is.

nnmail-expiry-wait-function: broke, or how-to?

[Mark Borges]

After reading the info page, I thought I could set the variable
`nnmail-expiry-wait-function' to get finer-grain control of the expiry
process. At least, that's what the doc-string:

------------------------------------------------------------------------------
nnmail-expiry-wait-function's value is [byte-code elided]

Documentation:
*Variable that holds function to specify how old articles should be
before they are expired.
  The function will be called with the name of the group that the
expiry is to be performed in, and it should return an integer that
says how many days an article can be stored before it is considered
'old'. 

Eg.:

(setq nnmail-expiry-wait-function
      (lambda (newsgroup)
        (cond ((string-match "private" newsgroup) 31)
              ((string-match "junk" newsgroup) 1)
	      (t 7))))
------------------------------------------------------------------------------

leads me to believe. So I set it to this:

------------------------------------------------------------------------------
(setq nnmail-expiry-wait-function (lambda (group)
			       (cond
				((string= "nnml:lists.zsh" group)
				 30)
				((string= "nnml:lists.xemacs" group)
				 10)
				((string= "nnml:lists.fvwm" group)
				 10)
				((string= "nnml:lists.NCARgraphics" group)
				 10)
				((string= "nnml:lists.raiders" group)
				 4)
				(t
				 7))
			       ))
------------------------------------------------------------------------------

But articles in my nnml mail folders are not being expired, e.g., I
still have an (unticked) article dated 13 Nov in my lists.fvwm mail
group, well beyond the 10 days I want to keep it. (BTW, will ticked
articles be excluded from the expiry process?).

So either (a) I'm misunderstanding how this works, or (b) it's broke.
But it can't possibly be (b), so it must be (a).

I know this function should work, because when I'm in the *Group*
buffer and eval this function:

------------------------------------------------------------------------------
(defun my-expiry-wait-function (group)
			       (cond
				((string= "nnml:lists.zsh" group)
				 30)
				((string= "nnml:lists.xemacs" group)
				 10)
				((string= "nnml:lists.fvwm" group)
				 10)
				((string= "nnml:lists.NCARgraphics" group)
				 10)
				((string= "nnml:lists.raiders" group)
				 4)
				(t
				 7))
			       )
------------------------------------------------------------------------------

via
	ESC-ESC (my-expiry-wait-function (gnus-group-group-name))

the correct integer gets returned.

I see there is a variable called `gnus-newsgroup-auto-expire', whose
value is nil by default, but it's doc-string:

------------------------------------------------------------------------------
Documentation:
not documented as a variable.
------------------------------------------------------------------------------

makes me a bit leery of messing with it.

Must I put gnus-group-expire-articles() on a hook function? If so, any
suggestions on which one? Ideally, I'd like Gnus to assume auto-expiry
of the groups I've gone to the trouble of listing in
nnmail-expiry-wait-function, but I can do anything; I just need a bit
more info.

Thanks,

  -mb-

Re: nnmail-expiry-wait-function: broke, or how-to?

[Steven L. Baur]

nnmail-expiry-wait-function is called with a newsgroup name sans method.

(setq nnmail-expiry-wait-function (lambda (group)
			       (cond
				((string= "nnml:lists.zsh" group)
				 30)
Replace the comparison with:
				((string= "lists.zsh" group)
and you'll be O.K.  The example in the manual shows something like
this without commentary, perhaps it should say something explicit.


In order for expiration to occur, you must manually set the expired
mark with the ``E'' command in the *Summary* buffer.

> I see there is a variable called `gnus-newsgroup-auto-expire', whose
> value is nil by default, but it's doc-string:
...
> makes me a bit leery of messing with it.

I'm leery of using it, but for other reasons.  Maybe after September
Gnus becomes Gnus 5.2 ...

Regards,
-- 
steve@miranova.com baur

Re: nnmail-expiry-wait-function: broke, or how-to?

[Mark Borges]

>> On 04 Dec 1995 13:29:45 -0800,
>> Steven L Baur(sb) wrote:
sb> nnmail-expiry-wait-function is called with a newsgroup name sans method.
sb> (setq nnmail-expiry-wait-function (lambda (group)
sb> 			       (cond
sb> 				((string= "nnml:lists.zsh" group)
sb> 				 30)
sb> Replace the comparison with:
sb> 				((string= "lists.zsh" group)
sb> and you'll be O.K.  The example in the manual shows something like
sb> this without commentary, perhaps it should say something explicit.

It doesn't seem to matter -- it appears to work fine with the method
left in. Should it? Lars?

sb> In order for expiration to occur, you must manually set the expired
sb> mark with the ``E'' command in the *Summary* buffer.

Hmm, after Robert's mail prompted me to set the variable `g-a-e-n', I
get the `E' mark automatically set now after I read the article if I
set it thusly,

------------------------------------------------------------------------------
gnus-auto-expirable-newsgroups's value is "nnml:lists\\.*"

Documentation:
*Groups in which to automatically mark read articles as expirable.
If non-nil, this should be a regexp that should match all groups in
which to perform auto-expiry.  This only makes sense for mail groups.
------------------------------------------------------------------------------

(BTW, do I need another (or less) backwhack? I'm trying to match the
string nnml:lists.*, where `.' and `.' are literal.)

But note that it is not "retro-active", in that I have to expose all
the old articles and read or mark them to expire them.

Anyway, thanks for the help.

  -mb-

Re: nnmail-expiry-wait-function: broke, or how-to?

[Lars Magne Ingebrigtsen]

mdb@cdc.noaa.gov (Mark Borges) writes:

> It doesn't seem to matter -- it appears to work fine with the method
> left in. Should it? Lars?

No, it shouldn't.  

-- 
Home is where the cat is.

Re: nnmail-expiry-wait-function: broke, or how-to?

[Robert Pluim]

>>>>> "Mark" == Mark Borges <mdb@cdc.noaa.gov> writes:
[correct setting of nnmail-expiry-wait-function deleted]

    Mark> But articles in my nnml mail folders are not being expired,
    Mark> e.g., I still have an (unticked) article dated 13 Nov in my
    Mark> lists.fvwm mail group, well beyond the 10 days I want to
    Mark> keep it. (BTW, will ticked articles be excluded from the
    Mark> expiry process?).

Are you explicitly marking the articles for expiry in the *Summary*
buffer by using 'E' ? (BTW ticked articles will be excluded, if by
ticked you mean marked using 'U')

    Mark> So either (a) I'm misunderstanding how this works, or (b)
    Mark> it's broke.  But it can't possibly be (b), so it must be
    Mark> (a).

It's (a), I think.

    Mark> Must I put gnus-group-expire-articles() on a hook function?
    Mark> If so, any suggestions on which one? Ideally, I'd like Gnus
    Mark> to assume auto-expiry of the groups I've gone to the trouble
    Mark> of listing in nnmail-expiry-wait-function, but I can do
    Mark> anything; I just need a bit more info.

You don't mention which version of ding you're using, but here goes
anyway.

You need to set gnus-auto-expirable-newsgroups to be a regexp which
matches the groups in which gnus will automatically *mark* articles
for expiry (note this is not the same as expiring them). You can then
expire articles in the group by using 'B e', or adding a hook,
probably to gnus-summary-prepare-exit-hook. (this is done by default
in some versions of ding)

See also the documentation for gnus-summary-prepare-exit-hook.

Hope this helps.

Robert

Re: nnmail-expiry-wait-function: broke, or how-to?

[Mark Borges]

>> On 04 Dec 1995 22:09:00 +0000,
>> Robert Pluim(rp) wrote:
>>>>>> "Mark" == Mark Borges <mdb@cdc.noaa.gov> writes:
rp> [correct setting of nnmail-expiry-wait-function deleted]

Mark> But articles in my nnml mail folders are not being expired,
Mark> e.g., I still have an (unticked) article dated 13 Nov in my
Mark> lists.fvwm mail group, well beyond the 10 days I want to
Mark> keep it. (BTW, will ticked articles be excluded from the
Mark> expiry process?).

rp> Are you explicitly marking the articles for expiry in the *Summary*
rp> buffer by using 'E' ? 

No, I was trying to avoid that and have Gnus do it (it does, as you
state below!)

rp> (BTW ticked articles will be excluded, if by ticked you mean
rp> marked using 'U')

Yes. Good, that's what I was hoping.

Mark> Must I put gnus-group-expire-articles() on a hook function?
Mark> If so, any suggestions on which one? Ideally, I'd like Gnus
Mark> to assume auto-expiry of the groups I've gone to the trouble
Mark> of listing in nnmail-expiry-wait-function, but I can do
Mark> anything; I just need a bit more info.

rp> You don't mention which version of ding you're using, but here goes
rp> anyway.

The latest (I think) -- Gnus-5.0.12. Or is there a Gnus-5.1 for XEmacs
(not Emacs-19.30) now?

rp> You need to set gnus-auto-expirable-newsgroups to be a regexp which
rp> matches the groups in which gnus will automatically *mark* articles
rp> for expiry (note this is not the same as expiring them). You can then
rp> expire articles in the group by using 'B e', or adding a hook,
rp> probably to gnus-summary-prepare-exit-hook. (this is done by default
rp> in some versions of ding)

Yep, this variable

------------------------------------------------------------------------------
gnus-auto-expirable-newsgroups's value is "nnml:lists\\.*"

Documentation:
*Groups in which to automatically mark read articles as expirable.
If non-nil, this should be a regexp that should match all groups in
which to perform auto-expiry.  This only makes sense for mail groups.
------------------------------------------------------------------------------

was the trick. And it's on the g-s-p-e-h hook by default in my copy of
Gnus.

rp> Hope this helps.

Yes, it did -- your reply was clear, helpful and right on. Thanks
again.

  -mb-