scoring

scoring

[Brian May]

Hello again,

according to the info documentation:

"Multiple crossposts"
     If you want to lower the score of articles that have been
     crossposted to more than, say, 3 groups:
          ("xref" ("[^:\n]+:[0-9]+ +[^:\n]+:[0-9]+ +[^:\n]+:[0-9]+" -1000 nil r))


However, this doesn't work, instead I have to use:

          ("xref" ("[^:]+:[0-9]+ +[^:]+:[0-9]+ +[^:]+:[0-9]+" -1000 nil r))

Which really puzzles me, as PGnus doesn't display any newlines
within the Xref line. Is that notation a legal R.E.? Or perhaps
PGnus removes newlines within the Xref line before displaying it?
How can I confirm/deny this? "C-u g" shows the Xref line, as expected,
without any newline characters.

(My guess is that the example is wrong, and PGnus interprets "\"
and "n" as two distinct characters, within [ and ] --- am I correct?
Perhaps this is a bug somewhere on my system.)


Another thing, while scoring based on the "Message-Id" works, scoring
based on "thread" doesn't work (nothing matches). This has me rather
puzzled, because I thought matching on thread is the same thing as
matching on the "Message-Id", but with followups included, too.
-- 
Brian May <bmay@csse.monash.edu.au>

Re: scoring

[Lars Magne Ingebrigtsen]

Brian May <bmay@csse.monash.edu.au> writes:

>           ("xref" ("[^:\n]+:[0-9]+ +[^:\n]+:[0-9]+ +[^:\n]+:[0-9]+" -1000 nil r))
> 
> However, this doesn't work, instead I have to use:
> 
>           ("xref" ("[^:]+:[0-9]+ +[^:]+:[0-9]+ +[^:]+:[0-9]+" -1000 nil r))
> 
> Which really puzzles me, as PGnus doesn't display any newlines
> within the Xref line. Is that notation a legal R.E.? Or perhaps
> PGnus removes newlines within the Xref line before displaying it?

The newline bits are in there to avoid having the score code go to
multi-line matching, which it will do, giving spurious results and
stuff. 

> (My guess is that the example is wrong, and PGnus interprets "\"
> and "n" as two distinct characters, within [ and ] --- am I correct?

No, Gnus reads the score files with `read', which will do the right
thing. 

So I don't understand this.  The [^:\n]+ should work while the [^:]+
should match articles where there aren't that many Xref headers.

> Another thing, while scoring based on the "Message-Id" works, scoring
> based on "thread" doesn't work (nothing matches). This has me rather
> puzzled, because I thought matching on thread is the same thing as
> matching on the "Message-Id", but with followups included, too.

Scoring on threads create lots of ADAPT files that it later uses when
scoring.  It seems to work for me...

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

Re: scoring

[Brian May]

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

    Lars> Brian May <bmay@csse.monash.edu.au> writes:
    >> ("xref" ("[^:\n]+:[0-9]+ +[^:\n]+:[0-9]+ +[^:\n]+:[0-9]+" -1000 nil r))
    >> 
    >> However, this doesn't work, instead I have to use:
    >> 
    >> ("xref" ("[^:]+:[0-9]+ +[^:]+:[0-9]+ +[^:]+:[0-9]+" -1000 nil r))
    >> 
    >> Which really puzzles me, as PGnus doesn't display any newlines
    >> within the Xref line. Is that notation a legal R.E.? Or perhaps
    >> PGnus removes newlines within the Xref line before displaying it?

    Lars> The newline bits are in there to avoid having the score code
    Lars> go to multi-line matching, which it will do, giving spurious
    Lars> results and stuff.

I know - however it doesn't work...

    >> (My guess is that the example is wrong, and PGnus interprets "\"
    >> and "n" as two distinct characters, within [ and ] --- am I correct?

    Lars> No, Gnus reads the score files with `read', which will do the right
    Lars> thing. 

    Lars> So I don't understand this.  The [^:\n]+ should work while the [^:]+
    Lars> should match articles where there aren't that many Xref headers.

It wasn't working.

In fact, I never have got any control characters to work within [ .. ] 
yet (except for ^). As this example is documented, I felt it should
work (and isn't just me doing something wrong).

My rule does do the right think, but perhaps that is coincidence in
that Xref usually is the last header.

    >> Another thing, while scoring based on the "Message-Id" works, scoring
    >> based on "thread" doesn't work (nothing matches). This has me rather
    >> puzzled, because I thought matching on thread is the same thing as
    >> matching on the "Message-Id", but with followups included, too.

    Lars> Scoring on threads create lots of ADAPT files that it later uses when
    Lars> scoring.  It seems to work for me...

I managed to get it to create the adapt file, with the correct
reference entries, etc. However, none of the articles were
being highlighted. I don't understand why.

Even more weird, it that scoring of "followups" works fine.
I believe the two are very similar.

PGnus 0.98
-- 
Brian May <bmay@csse.monash.edu.au>

Re: scoring

[Kai Großjohann]

Brian May <bmay@csse.monash.edu.au> writes:

> In fact, I never have got any control characters to work within [ .. ] 
> yet (except for ^). As this example is documented, I felt it should
> work (and isn't just me doing something wrong).

Well, the Lisp reader turns \n into a real newline character, and the
regex engine groks real newline characters.  Customize, however, does
not turn \n into a real newline character, so you have to use C-q C-j
there.

Maybe that was it?  Excuse me if this was a stupid idea.

kai
-- 
A preposition is not a good thing to end a sentence with.

Re: scoring

[Brian May]

>>>>> "Kai" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

    Kai> Well, the Lisp reader turns \n into a real newline character,
    Kai> and the regex engine groks real newline characters.
    Kai> Customize, however, does not turn \n into a real newline
    Kai> character, so you have to use C-q C-j there.

    Kai> Maybe that was it?  Excuse me if this was a stupid idea.

Thanks - that probably was it.

It not as good having to directly embed a newline character directly
into Customize though, but I guess this isn't PGnus fault.

Perhaps this should be documented somewhere in the PGnus
documentation?
-- 
Brian May <bmay@csse.monash.edu.au>

Re: scoring

[Lars Magne Ingebrigtsen]

Brian May <bmay@csse.monash.edu.au> writes:

> Perhaps this should be documented somewhere in the PGnus
> documentation?

I think Customize should grok \n and the like.

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

Re: scoring

[Jan Vroonhof]

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

> > Perhaps this should be documented somewhere in the PGnus
> > documentation?
> 
> I think Customize should grok \n and the like.

Customize uses the normal lisp reader, so i really don't see why it
shouldn't work.

Older versions of customize (at least in XEmacs) did have some
problems when writing out stuff, but those should be fixed in recent
versions..


Jan

Re: scoring

[Per Abrahamsen]

Jan Vroonhof <vroonhof@math.ethz.ch> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
> > > Perhaps this should be documented somewhere in the PGnus
> > > documentation?
> > 
> > I think Customize should grok \n and the like.
> 
> Customize uses the normal lisp reader, so i really don't see why it
> shouldn't work.

For `sexp' widgets, not for `string' widgets.  

I don't think `\' should mean anything else than `\' in a ordinary
text field.  The people who can memorize the various escape sequences
and remember to double (quad-ruble in regexps) the backslashes aren't
the primary target for Customize.

Re: scoring

[Hrvoje Niksic]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> I don't think `\' should mean anything else than `\' in a ordinary
> text field.

Agreed.

Re: scoring

[Kai Großjohann]

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

> I think Customize should grok \n and the like.

Why?  When interactively searching for a regexp, you also type C-q C-j
if you want to search for a newline, so why can't people type C-q C-j
in Customize buffers?

And then, there's the possibility of switching Customize to the Lisp
representation, where (I think) regexes are (Lisp) strings, so \n
works there.

kai
-- 
A preposition is not a good thing to end a sentence with.

Re: scoring

[Brian May]

>>>>> "Kai" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

    Kai> Why?  When interactively searching for a regexp, you also
    Kai> type C-q C-j if you want to search for a newline, so why
    Kai> can't people type C-q C-j in Customize buffers?

I personally think that a regexp looks "messy" when it is broken up by
newlines, especially when the newlines occur with [ and ].

As an example:

[^:\n]+:[0-9]+ +[^:\n]+:[0-9]+ +[^:\n]+:[0-9]+

now looks like:

[^:
]+:[0-9]+ +[^:
]+:[0-9]+ +[^:
]+:[0-9]+

I can't imagine any possible reason why you might want to search for
\, but perhaps I am mistaken. I think it is more confusing to the
beginner that \n is interpreted differently, depending on how it is
used.

    Kai> And then, there's the possibility of switching Customize to
    Kai> the Lisp representation, where (I think) regexes are (Lisp)
    Kai> strings, so \n works there.

True - but then you miss out on the advantages of Customize, and have
to go searching the documentation to find out the correct format
for the LISP expression.

-- 
Brian May <bmay@csse.monash.edu.au>

Re: scoring

[Per Abrahamsen]

Brian May <bmay@csse.monash.edu.au> writes:

> I can't imagine any possible reason why you might want to search for
> \, but perhaps I am mistaken.

But ``\(foo\|bar\)'' would look like ``"\\(foo\\|bar\\)"'' if these
fields used the sexp widget instead of the regexp widget.  `\' is used
a lot in regexps.

One could of course come up with a new meaning of `\' that doesn't
correspond to what you tell the Lisp reader, nor to what is described
in the Regexp section of the manual, nor to what is expected by
commands such as `isearch-forward-regexp'.  I believe that would be
evil.

The current syntax is the same as the syntax expected by
`isearch-forward-regexp'.

Re: scoring

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> One could of course come up with a new meaning of `\' that doesn't
> correspond to what you tell the Lisp reader, nor to what is described
> in the Regexp section of the manual, nor to what is expected by
> commands such as `isearch-forward-regexp'.  I believe that would be
> evil.

Yup.

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

scoring

[michael lamoureux]

In some randomly old version of ding or sgnus or something this
used to work:

comp.lang.postscript.KILL:
(gnus-kill "Subject" "convert\\|conversion\\|HPGL\\|->\\|filter\\|viewer\\|ghost\\|windows\\|laserjet\\|deskjet\\|inkjet\\|gs3\\|aladdin\\|acrobat\\|pdf")
(gnus-expunge "X")

I noticed today (I haven't read the group in months) that this wasn't
working anymore, so rather than figure out why, I just tried to do
this:

comp.lang.postscript.SCORE:
(("subject"
  ("conver" -1000 nil e)
  ("HPGL" -1000 nil e)
  ("->" -1000 nil e)
  ("filter" -1000 nil e)
  ("viewer" -1000 nil e)
  ("ghost" -1000 nil e)
  ("windows" -1000 nil e)
  ("95" -1000 nil e)
  ("jet" -1000 nil e)
  ("gs3" -1000 nil e)
  ("aladdin" -1000 nil e)
  ("acrobat" -1000 nil e)
  ("pdf" -1000 nil e)))


Still didn't work.  So, I tried customize score file, and it keeps
wanting to edit ~/news/SCORE.  What's that?  I thought the generic
score file was all.SCORE.  And why wouldn't the current score file be
comp.lang.postscript.SCORE while I was in that newsgroup.  When I try
to open this file in customize, it complains that this file isn't a
buffer (??!?).

related variables:
(setq gnus-directory "~/news/"
      gnus-kill-files-directory "~/news/"
      gnus-use-scoring t
      gnus-use-adaptive-scoring t
      gnus-score-find-score-files-function 'gnus-score-find-bnews)


Oh, and when I try to edit a score file, gnus says to run some
function when I'm done (sorry, don't have the name handy).  It doesn't
exist.  (And why wouldn't that function just be bound to "C-c C-c"
like everything else?)


XEmacs 19.13, gnus 5.2.15


lost,
Michael

caveat> the pipes burst next door today, so there's no coffee at the
caveat> coffee shop...this might be obvious.

Re: scoring

[Lars Magne Ingebrigtsen]

michael lamoureux <lamour@engin.umich.edu> writes:

> I noticed today (I haven't read the group in months) that this wasn't
> working anymore, so rather than figure out why, I just tried to do
> this:
> 
> comp.lang.postscript.SCORE:
> (("subject"
>   ("conver" -1000 nil e)
>   ("HPGL" -1000 nil e)

`e' is "exact match".  You want `s'.

> Still didn't work.  So, I tried customize score file, and it keeps
> wanting to edit ~/news/SCORE.  What's that?  I thought the generic
> score file was all.SCORE.  And why wouldn't the current score file be
> comp.lang.postscript.SCORE while I was in that newsgroup.  When I try
> to open this file in customize, it complains that this file isn't a
> buffer (??!?).

`(setq debug-on-error t)', repeat the bug and mail me the backtrace.

> Oh, and when I try to edit a score file, gnus says to run some
> function when I'm done (sorry, don't have the name handy).  It doesn't
> exist.  (And why wouldn't that function just be bound to "C-c C-c"
> like everything else?)

That's what it's supposed to say.  Fix in Gnus v5.2.16.

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

Re: scoring

[Steven L Baur]

>>>>> "michael" == michael lamoureux <lamour@engin.umich.edu> writes:

michael> In some randomly old version of ding or sgnus or something this
michael> used to work:

michael> comp.lang.postscript.KILL:
michael> (gnus-kill "Subject" "convert\\|conversion\\|HPGL\\|->\\|filter\\|viewer\\|ghost\\|windows\\|laserjet\\|deskjet\\|inkjet\\|gs3\\|aladdin\\|acrobat\\|pdf")
michael> (gnus-expunge "X")
...
michael> Still didn't work.  So, I tried customize score file, and it keeps
michael> wanting to edit ~/news/SCORE.  What's that?

This is a result of the backend separation code recently added.
You need to set both gnus-use-long-file-name *and*
nnmail-use-long-file-names in order for things to work as they have in
the past.

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