New features + feature freeze?

New features + feature freeze?

[Lars Magne Ingebrigtsen]

I've been whittling away on the todo list, and it's now down to only
75 remaining items.  :-)  At this rate, they may all be done by New
Year.  

So perhaps there should be a new feature freeze in January so that we
can get September working reliably.  Two months beta, and then we
should have Gnus 5.2 ready for general usage Marchish? 

(I probably shouldn't say this, but...)  If you have ideas for
anything neat that you think definitely should be in Gnus, you should
probably speak up soon(ish), or it'll have to wait until April.

To take a look at the current (sort of; I've now shaved off 20 items)
todo list, point your Web Thing to
<URL:http://www.ifi.uio.no/~larsi/sgnus/todo>.  In fact, the entire
actual September development directory is there.  It's usually a
couple of days out of date since I write most code at my home
machine. 

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

Re: New features + feature freeze?

[Wes Hardaker]

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

|> (I probably shouldn't say this, but...)  If you have ideas for
|> anything neat that you think definitely should be in Gnus, you should
|> probably speak up soon(ish), or it'll have to wait until April.

Heh heh...  Yesterday and the day before, I implemented a hack into
the faces database.  The top of all my articles now have icons
representing the news groups, the users face (if exists), and the
users domain icons.  Looks really cool.  This works with XEmacs;  I
don't have Emacs compiled (its on my todo list), but I doubt it'll
work as is.  The two important XEmacs functions I'm using are
make-glyph and make-annotation.  Are these supported under the Gnu Emacs
side of things?
                                                                _____ 
Wes Hardaker                                                   / ___ \
Department of Electrical and Computer Engineering             / /   \//\
University of California at Davis        __________________  \--/    /--\
Davis CA  95616                         /     Recycle!     \  \//\___/ /
(hardaker@ece.ucdavis.edu)             / It's not too late! \   \_____/

Re: New features + feature freeze?

[William Perry]

Wes Hardaker writes:
> 
> Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> 
> |> (I probably shouldn't say this, but...)  If you have ideas for
> |> anything neat that you think definitely should be in Gnus, you should
> |> probably speak up soon(ish), or it'll have to wait until April.
> 
> Heh heh...  Yesterday and the day before, I implemented a hack into the
> faces database.  The top of all my articles now have icons representing
> the news groups, the users face (if exists), and the users domain icons.
> Looks really cool.  This works with XEmacs; I don't have Emacs compiled
> (its on my todo list), but I doubt it'll work as is.  The two important
> XEmacs functions I'm using are make-glyph and make-annotation.  Are these
> supported under the Gnu Emacs side of things?

  Images do not work _at all_ under GNU Emacs, so this is futile to try and
port.  Should definitely be in the XEmacs section of code though.  Are you
relying on XFace support being compiled in, or can you use
facetoicon|icontoxbm filters as well like highlight-headers?

  Would be nice if this wasn't just relegated to XFace as well.  If I put
an X-GIF or something in there, would be cool to have it show up.  XEmacs
19.14 will have built in GIF, JPEG, and PNG support as well, so it wouldn't
even be slow for most users. :)

  The redisplay code from XEmacs has been signed over to the FSF, so this
will be possible as soon as that is merged in, but right now there is
nobody to work on it.  Any volunteers? :)  Talk to rms, please. :)

-Bill P.

Re: New features + feature freeze?

[Wes Hardaker]

William Perry <wmperry@spry.com> writes:

|>   Images do not work _at all_ under GNU Emacs, so this is futile to try and
|> port.  Should definitely be in the XEmacs section of code though.  Are you
|> relying on XFace support being compiled in, or can you use
|> facetoicon|icontoxbm filters as well like highlight-headers?

Currently I haven't added the x-face header support yet...  Its on my
todo list though (should be simple enough).  Anyway, it currently uses
the picons database of stuff (look at
http://www.cs.indiana.edu/picons/ftp/index.html).

|>   Would be nice if this wasn't just relegated to XFace as well.  If I put
|> an X-GIF or something in there, would be cool to have it show up.  XEmacs
|> 19.14 will have built in GIF, JPEG, and PNG support as well, so it wouldn't
|> even be slow for most users. :)

The picons database has support for three types:  xpm, gif, xbm.
Currently, I'm only using xpm and xbm since I think there are no gif
files in the database that don't have a matching xpm file.

Wes

picons support (was Re: New features + feature freeze?)

[Ben Gross]

Wes Hardaker <hardaker@ece.ucdavis.edu> wrote:
>
>William Perry <wmperry@spry.com> writes:
>
>|>   Images do not work _at all_ under GNU Emacs, so this is futile to try and
>|> port.  Should definitely be in the XEmacs section of code though.  Are you
>|> relying on XFace support being compiled in, or can you use
>|> facetoicon|icontoxbm filters as well like highlight-headers?
>
>Currently I haven't added the x-face header support yet...  Its on my
>todo list though (should be simple enough).  Anyway, it currently uses
>the picons database of stuff (look at
>http://www.cs.indiana.edu/picons/ftp/index.html).

I have been using the faces from the X-face header for a while now in
EXMH. I recently installed some of the picons databases.  The visual
recognition of an individual is much nicer than looking at the from header.

>|>   Would be nice if this wasn't just relegated to XFace as well.  If I put
>|> an X-GIF or something in there, would be cool to have it show up.  XEmacs
>|> 19.14 will have built in GIF, JPEG, and PNG support as well, so it wouldn't
>|> even be slow for most users. :)
>
>The picons database has support for three types:  xpm, gif, xbm.
>Currently, I'm only using xpm and xbm since I think there are no gif
>files in the database that don't have a matching xpm file.

I would recommend also supporting gif as I believe there are a number of
icons that do not have a matching xpm file. I know at least locally that
this is the case, and I think it may also be true in the domain database in
some instances.

Great work on supporting picons though, I hope more applications begin to
use it in the future as we move towards more visual and personable
interfaces. :)

Thanks,
Ben Gross

--
"Wait a minute, Juanita.  Make up your mind.  This Snow Crash thing--is it
a virus, a drug, or a religion?" Juanita shrugs. "What's the difference?"
    ---Neal Stephenson "Snow Crash"
Ben Gross  Email: bgross@uiuc.edu  URL: http://www.uiuc.edu/ph/www/bgross

Re: New features + feature freeze?

[Lars Magne Ingebrigtsen]

Wes Hardaker <hardaker@ece.ucdavis.edu> writes:

> Heh heh...  Yesterday and the day before, I implemented a hack into
> the faces database.  The top of all my articles now have icons
> representing the news groups, the users face (if exists), and the
> users domain icons.  Looks really cool. 

Hey; great!  Doing something like that was on the todo list, and now I
don't have to do it!  :-)

Could you mail it to me (or to the list)?

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

Re: New features + feature freeze?

[Wes Hardaker]

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

|> Wes Hardaker <hardaker@ece.ucdavis.edu> writes:
|> 
|> > Heh heh...  Yesterday and the day before, I implemented a hack into
|> > the faces database.  The top of all my articles now have icons
|> > representing the news groups, the users face (if exists), and the
|> > users domain icons.  Looks really cool. 
|> 
|> Hey; great!  Doing something like that was on the todo list, and now I
|> don't have to do it!  :-)
|> 
|> Could you mail it to me (or to the list)?

I'll try to clean it up a bit and rename the functions and create some
variables and silly portability type things like that and mail it off
today or tommorrow.  

Currently it puts all the pictures at the top of the article.  I
actually want to put them in a seperate buffer (a special faces buffer
or something).  That way you can configure where you want it with
gnus-add-configuration.  You'll also get the group icons at entry to
the group rather than at the first article read...  

Anyway, Lars:  You've just released sgnus 0.22 with some XEmacs
graphics, and you just mentioned you wanted the above code...  Does
this mean you're reading news in XEmacs now?  (heh heh)

Wes

Re: New features + feature freeze?

[William Perry]

Wes Hardaker writes:
> 
> Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> 
> |> Wes Hardaker <hardaker@ece.ucdavis.edu> writes:
> |> 
> |> > Heh heh...  Yesterday and the day before, I implemented a hack into
> |> > the faces database.  The top of all my articles now have icons
> |> > representing the news groups, the users face (if exists), and the
> |> > users domain icons.  Looks really cool. 
> |> 
> |> Hey; great!  Doing something like that was on the todo list, and now I
> |> don't have to do it!  :-)
> |> 
> |> Could you mail it to me (or to the list)?
> 
> I'll try to clean it up a bit and rename the functions and create some
> variables and silly portability type things like that and mail it off
> today or tommorrow.  
> 
> Currently it puts all the pictures at the top of the article.  I
> actually want to put them in a seperate buffer (a special faces buffer
> or something).  That way you can configure where you want it with
> gnus-add-configuration.  You'll also get the group icons at entry to
> the group rather than at the first article read...  

  Hmmmmm ... what about sticking them in (a/the) toolbar?

> Anyway, Lars:  You've just released sgnus 0.22 with some XEmacs
> graphics, and you just mentioned you wanted the above code...  Does
> this mean you're reading news in XEmacs now?  (heh heh)

  As well he should. :)

-Bill P.

Re: New features + feature freeze?

[Wes Hardaker]

William Perry <wmperry@spry.com> writes:

|>   Hmmmmm ... what about sticking them in (a/the) toolbar?

They are too large for the tool bar (48x48).  Besides, they are not
tools.  They are nothing more than pretty pictures.

|> > Anyway, Lars:  You've just released sgnus 0.22 with some XEmacs
|> > graphics, and you just mentioned you wanted the above code...  Does
|> > this mean you're reading news in XEmacs now?  (heh heh)
|> 
|>   As well he should. :)

Well, I'm not going to bite into that argument.

Wes

Re: New features + feature freeze?

[Lars Magne Ingebrigtsen]

Wes Hardaker <hardaker@ece.ucdavis.edu> writes:

> Currently it puts all the pictures at the top of the article.  I
> actually want to put them in a seperate buffer (a special faces buffer
> or something).  

Both would be nice -- perhaps a variable to say whether to do it in a
separate buffer or in the article buffer?

> That way you can configure where you want it with
> gnus-add-configuration.

Yup.  Hm, that means that I should probably make it possible to have
`frame' in the window-configuration right away.  A buffer like that
would probably look best in a frame of its own, perhaps...
(User-configurable, of course.)

> Anyway, Lars:  You've just released sgnus 0.22 with some XEmacs
> graphics, and you just mentioned you wanted the above code...  Does
> this mean you're reading news in XEmacs now?  (heh heh)

No, I'm still using Emacs for work, but if I want to show people
"Look!  I've done that!  Me!" then it's better to have something a bit
more, like, flashy...  :-)  Next I'm doing an animation of a little
man walking to the newsstand to get news that's being run when you tap
`g'.  It'll only mean that your XEmacs will be halted for, oh, 30
seconds while it runs.  I'm sure y'all won't mind.  :-=  

(Jokejokejoke.)

-- 
Home is where the cat is.

Re: New features + feature freeze?

[Wes Hardaker]

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

|> Wes Hardaker <hardaker@ece.ucdavis.edu> writes:
|> 
|> > Currently it puts all the pictures at the top of the article.  I
|> > actually want to put them in a seperate buffer (a special faces buffer
|> > or something).  
|> 
|> Both would be nice -- perhaps a variable to say whether to do it in a
|> separate buffer or in the article buffer?

Yeah...  My thoughts exactly.

|> > That way you can configure where you want it with
|> > gnus-add-configuration.
|> 
|> Yup.  Hm, that means that I should probably make it possible to have
|> `frame' in the window-configuration right away.  A buffer like that
|> would probably look best in a frame of its own, perhaps...
|> (User-configurable, of course.)

That would be fine too, of course...  I personally would never do
that, since I like to keep all my related windows in one frame.  (Why
is Emacs terminology different from general UI terminoligy?  Couldn't
we have called frames=windows, windows=sub-windows or something? sigh...)

Anyway, one last question before I wrap this up and mail it to y'all:
Whats the proper way to get the author's email address from an
article?  Currently, I'm hacking it from the article buffer (ick).
Its got to be stuck in a variable somewhere?  (I'm tired of code
searching).

Wes

Re: New features + feature freeze?

[Lars Magne Ingebrigtsen]

Wes Hardaker <hardaker@ece.ucdavis.edu> writes:

> Anyway, one last question before I wrap this up and mail it to y'all:
> Whats the proper way to get the author's email address from an
> article?  Currently, I'm hacking it from the article buffer (ick).
> Its got to be stuck in a variable somewhere? 

Most information on an article is kept in a `mail-header' vector, and
you access the relevant parts with the `mail-header-' macros, like
`mail-header-from'. 

If you have the article number, you get the From header with, say
`(mail-header-from (gnus-summary-article-header NUMBER))'.

-- 
Home is where the cat is.

Re: New features + feature freeze?

[Steven L. Baur]

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

    Lars> No, I'm still using Emacs for work, but if I want to show
    Lars> people "Look!  I've done that!  Me!" then it's better to
    Lars> have something a bit more, like, flashy...  :-) Next I'm
    Lars> doing an animation of a little man walking to the newsstand
    Lars> to get news that's being run when you tap `g'.  It'll only
    Lars> mean that your XEmacs will be halted for, oh, 30 seconds
    Lars> while it runs.  I'm sure y'all won't mind.  :-=

That would be pretty neat actually, and if you ran the animation
instead of printing dots that (*most* annoyingly) disappear fairly
quickly while Gnus is thinking, it would even be useful.  30 seconds
is not a long time compared to how long it takes to reread the active
file and fetch spooled mail.

I know this comment was intended to be humorous, but it would be fun ...
-- 
steve@miranova.com baur

Re: New features + feature freeze?

[Lars Magne Ingebrigtsen]

Wes Hardaker <hardaker@ece.ucdavis.edu> writes:

> Currently it puts all the pictures at the top of the article.  I
> actually want to put them in a seperate buffer (a special faces buffer
> or something).  

Both would be nice -- perhaps a variable to say whether to do it in a
separate buffer or in the article buffer?

> That way you can configure where you want it with
> gnus-add-configuration.

Yup.  Hm, that means that I should probably make it possible to have
`frame' in the window-configuration right away.  A buffer like that
would probably look best in a frame of its own, perhaps...
(User-configurable, of course.)

> Anyway, Lars:  You've just released sgnus 0.22 with some XEmacs
> graphics, and you just mentioned you wanted the above code...  Does
> this mean you're reading news in XEmacs now?  (heh heh)

No, I'm still using Emacs for work, but if I want to show people
"Look!  I've done that!  Me!" then it's better to have something a bit
more, like, flashy...  :-)  Next I'm doing an animation of a little
man walking to the newsstand to get news that's being run when you tap
`g'.  It'll only mean that your XEmacs will be halted for, oh, 30
seconds while it runs.  I'm sure y'all won't mind.  :-=  

(Jokejokejoke.)

-- 
Home is where the cat is.

Re: New features + feature freeze?

[Jens Lautenbacher]

Oh, two or three days ago someone mentioned here or in the newsgroup
that he would like to have the possibility to merge face definitions
with existing ones. 

So we should add a second pass to the fontification. Right now
fontification stops after the first true condition it encounters in
the list. In the second pass it should do all things with a true
condition. These should be no real face definitions but functions like
gnus-make-face-bold, or ...-italic, or (gnus-make-face-size 14), that
means functions that use an existing face in the region they operate
on.

What I would use this for:

    I would really like to have the root of my threads (where also the
    subject appears) say in 14 point size and all the follow-ups in
    12. So the condition would be 'is the article a root' and the
    function would be (gnus-make-face-size 12) if not or the other way
    around. (-> I know there will be problems with dummy roots, I
    tried it already)


By the way, I use XEmacs....

Nice logo.


        

Re: New features + feature freeze?

[Lars Magne Ingebrigtsen]

Jens Lautenbacher <jtl@tkm.physik.uni-karlsruhe.de> writes:

> Oh, two or three days ago someone mentioned here or in the newsgroup
> that he would like to have the possibility to merge face definitions
> with existing ones. 
> 
> So we should add a second pass to the fontification. Right now
> fontification stops after the first true condition it encounters in
> the list. In the second pass it should do all things with a true
> condition. These should be no real face definitions but functions like
> gnus-make-face-bold, or ...-italic, or (gnus-make-face-size 14), that
> means functions that use an existing face in the region they operate
> on.

Hmmm...  yes, that would make sense.  I don't know much about fonts
and visual stuff in general -- I'm a luddite.  I like black-and-white
screens, just like they had in the good old days.  Colors!  Feh!

But if somebody would like to supply patches to do things like this...

-- 
Home is where the cat is.

Re: New features + feature freeze?

[Jens Lautenbacher]

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

    LMI> Wes Hardaker <hardaker@ece.ucdavis.edu> writes:
    >> Heh heh...  Yesterday and the day before, I implemented a hack
    >> into the faces database.  The top of all my articles now have
    >> icons representing the news groups, the users face (if exists),
    >> and the users domain icons.  Looks really cool.

    LMI> Hey; great!  Doing something like that was on the todo list,
    LMI> and now I don't have to do it!  :-)
    LMI> Could you mail it to me (or to the list)?

I could think of some useful extensions to the things Wes has already
coded. What would you think of recognizing that a article has a
uuencoded (part of) a/some picture(s) in it, and just hide the crazy
numbers and stuff a pressable picture into the article to actually
start the uudecoding and viewing?

Use xpm-buttons for pressable buttons in the articles (get the text
that should end as a button as now, feed it to xpm-buttons, hide the
text, put the glyph into the article. could be cumbersome to deal with
the wordwrap, though.

I hope I'll get my fingers on Wes' code soon, so I can find some time
(maybe) for doing a little more than bugfixing...

Re: New features + feature freeze?

[Wes Hardaker]

Jens Lautenbacher <jtl@tkm.physik.uni-karlsruhe.de> writes:

|> I hope I'll get my fingers on Wes' code soon, so I can find some time
|> (maybe) for doing a little more than bugfixing...

Well, its pretty much ready to go.  I'm just trying to figure out why
I'm gaining memory.  It looks like XEmacs keeps a cache of all the
glyphs you ever make, thus increasing the memory size of the
application by leaps and bounds if you turn this on while running
gnus.  I can't figure out anyway to kill created glyphs.  Ideas?

Wes

Re: New features + feature freeze?

[Wes Hardaker]

Wes Hardaker <hardaker@ece.ucdavis.edu> writes:

|> Well, its pretty much ready to go.  I'm just trying to figure out why
|> I'm gaining memory.  It looks like XEmacs keeps a cache of all the
|> glyphs you ever make, thus increasing the memory size of the
|> application by leaps and bounds if you turn this on while running
|> gnus.  I can't figure out anyway to kill created glyphs.  Ideas?

Ack...  I just turned off the icons code and read gnus to see if it
was my code or gnus that was eating memory.  Its gnus.  

Lars, have you looked into the variables you create and their size?
Maybe we should zero out some of the larger ones until the next run?
Using 'ps' I discovered XEmacs jumped up about 200 memory blocks
(almost a meg of memory (If I'm getting the block size correctly)).

Wes

Re: New features + feature freeze?

[Lars Magne Ingebrigtsen]

Wes Hardaker <hardaker@ece.ucdavis.edu> writes:

> Ack...  I just turned off the icons code and read gnus to see if it
> was my code or gnus that was eating memory.  Its gnus.  
> 
> Lars, have you looked into the variables you create and their size?
> Maybe we should zero out some of the larger ones until the next run?
> Using 'ps' I discovered XEmacs jumped up about 200 memory blocks
> (almost a meg of memory (If I'm getting the block size correctly)).

You mean that XEmacs only grows by 1Mb when you start Gnus?  That's
not a lot, in my opinion.  Now, if you get 16Mb growth, then I would
be a bit more worried...  :-)

But what do you mean by "zero out some of the larger ones"?  Zero out
variables?  

-- 
Home is where the cat is.

Re: New features + feature freeze?

[Wes Hardaker]

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

|> You mean that XEmacs only grows by 1Mb when you start Gnus?  That's
|> not a lot, in my opinion.  Now, if you get 16Mb growth, then I would
|> be a bit more worried...  :-)

No no...  It grows by 1Mb EVERY time I run Gnus.  Meaning, even in an
emacs that I all ready ran Gnus in once.  It has all ready loaded the
code, so thats not it.  And that 1 Mb figure was from reading only
about 5 groups.  It grows by a lot more if I read more groups (which
is more typical).

|> But what do you mean by "zero out some of the larger ones"?  Zero out
|> variables?  

Yeah.  Set them to 'nil.  Particularily things like gnus-newsrc-alist,
which is reloaded when Gnus is re-run, so its pointless to keep the
information store in them.  For instance, gnus-newsrc-alist is pretty
much the majority of ~/.gnus.eld, and that file (for me) is 100k+.
This means that 100k of my Emacs memory is just for this variable.
This could be set to 'nil on exit.  You'ld have a better idea than me
for nil'ing other variables on exit as well.  I don't know how many
others are appropriate though.  

This is only an idea of course, but a good one considering how large
of a package Gnus is.

|> Home is where the cat is.

You obviously don't let your cat wander around outside like most of
mine do.  Hell, some times I've owned cats that live in 3 or 4 houses
(or who ever will feed him).  ;-)

Re: New features + feature freeze?

[Lars Magne Ingebrigtsen]

Wes Hardaker <hardaker@ece.ucdavis.edu> writes:

> No no...  It grows by 1Mb EVERY time I run Gnus. 

Oh.  That's not good.  If you're reading nnmh groups, you'll get
bitten by the insert-file-contents/gc bug...

> |> But what do you mean by "zero out some of the larger ones"?  Zero out
> |> variables?  
> 
> Yeah.  Set them to 'nil.  Particularily things like gnus-newsrc-alist,
> which is reloaded when Gnus is re-run, so its pointless to keep the
> information store in them. 

`gnus-clear-system' does set most Gnus variables to nil on exit.  Even
if it didn't do that, Emacs shouldn't grow each time you start Gnus.
That's what we have garbage collection to handle...

> |> Home is where the cat is.
> 
> You obviously don't let your cat wander around outside like most of
> mine do.  Hell, some times I've owned cats that live in 3 or 4 houses
> (or who ever will feed him).  ;-)

I've been cat-less for a while now, and am just expressing my sorrow
at not having a home since I don't have a cat.  *Sob*.

Well, I'll live.  Just not happily.

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

Re: New features + feature freeze?

[William Perry]

Wes Hardaker writes:
> 
> Jens Lautenbacher <jtl@tkm.physik.uni-karlsruhe.de> writes:
> 
> |> I hope I'll get my fingers on Wes' code soon, so I can find some time
> |> (maybe) for doing a little more than bugfixing...
> 
> Well, its pretty much ready to go.  I'm just trying to figure out why
> I'm gaining memory.  It looks like XEmacs keeps a cache of all the
> glyphs you ever make, thus increasing the memory size of the
> application by leaps and bounds if you turn this on while running
> gnus.  I can't figure out anyway to kill created glyphs.  Ideas?

  Are you using the relocating allocation?  If not, no memory is ever freed
back to the OS, and glyphs take up space like anything else.

  Make sure you are dropping all pointers to the created glyphs, or XEmacs
won't GC them and colors/ximages won't be unallocated either.  Bad bad bad. :)

-Bill P.

Re: New features + feature freeze?

[Wes Hardaker]

William Perry <wmperry@spry.com> writes:

|>   Are you using the relocating allocation?  If not, no memory is ever freed
|> back to the OS, and glyphs take up space like anything else.

Yep.

|>   Make sure you are dropping all pointers to the created glyphs, or XEmacs
|> won't GC them and colors/ximages won't be unallocated either.  Bad
|> bad bad. 

The picons database uses a set color pallet.  It'll never use more
than the pallet since the color values of the icons are fixed.  (they
actually have two pallets.  One for grey scale images, and one for
color).  The cool thing is that exmh and gnus can use the same pallet
for all the icons being displayed at one time.  Bonus.

Wes

Re: New features + feature freeze?

[Kai Grossjohann]

>>>>> On 13 Dec 1995 19:22:07 +0100, Lars Magne Ingebrigtsen
>>>>> <larsi@ifi.uio.no> said:

  Lars> (I probably shouldn't say this, but...)  If you have ideas for
  Lars> anything neat that you think definitely should be in Gnus, you
  Lars> should probably speak up soon(ish), or it'll have to wait
  Lars> until April.

Just yesterday and today I thought WIBNI...

So here goes, though I'm still using Gnus 5.1 so I don't know if this
is in sgnus already.

I have a group which is a mail archive encompassing several months'
worth of mails.  (It's about 650 messages, now.)  Now, when I browse
this archive I find I want to often switch between threaded and
unthreaded mode.  Say I'm looking for a mail from the day before
yesterday which must be near the end in a no-threads listing.  So for
searching for this mail I would prefer to turn off threads.  Then,
when I have found the mail, I would like to look at the whole thread,
though.

I could turn on threading at this point but that takes quite some
time.  Turning off threading again also takes quite some time.  WIBNI
there would be some smaller granularity for threading, such as a way
of gathering the current thread (ie the thread containing the current
message)?  It could be displayed in the current Summary buffer, or a
new Summary buffer could be created for this.

And then there's this totally cool Information Retrieval feature:
Devise some useful way of displaying any message at all.  Here's the
setting:  Suppose I use WAIS (freeWAIS-sf, in particular) to index my
Mail subdirectory (containing nnml groups).  I can then run a
waissearch program which gives me a list of results.

I would then want to do two things:

  - Look at the list of results in a meaningful way.  This shouldn't
    be so difficult, I can just print a list and have the user choose
    an item.
  - Look at a message in a meaningful way.  Does this mean selecting
    the group the message is in, then selecting the right message?
    Does this mean displaying the thread the message is in?  What else
    can you think of?

I think I really want three different levels of granularity: One level
displaying a list of search results, one level displaying some context
of one message in the search result, and one level for displaying a
message.  Could use the normal *Article* buffer for the last one.

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

Re: New features + feature freeze?

[Lars Magne Ingebrigtsen]

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

> I could turn on threading at this point but that takes quite some
> time.  Turning off threading again also takes quite some time.  WIBNI
> there would be some smaller granularity for threading, such as a way
> of gathering the current thread (ie the thread containing the current
> message)?  

Actually, that's not only possible -- it's trivial.  It's just a call
to `gnus-rebuild-thread' with a small wrapper around.  I've added it
to the todo list.

> And then there's this totally cool Information Retrieval feature:
> Devise some useful way of displaying any message at all.  Here's the
> setting:  Suppose I use WAIS (freeWAIS-sf, in particular) to index my
> Mail subdirectory (containing nnml groups).  I can then run a
> waissearch program which gives me a list of results.

I think that would require writing an nnwais (or something) backend.
Since I don't use WAIS, I'm not the person to write such a beast.  So
perhaps somebody else feels the call?

-- 
Home is where the cat is.

Re: New features + feature freeze?

[Steven L. Baur]

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

    >> And then there's this totally cool Information Retrieval
    >> feature: Devise some useful way of displaying any message at
    >> all.  Here's the setting: Suppose I use WAIS (freeWAIS-sf, in
    >> particular) to index my Mail subdirectory (containing nnml
    >> groups).  I can then run a waissearch program which gives me a
    >> list of results.

    Lars> I think that would require writing an nnwais (or something)
    Lars> backend. Since I don't use WAIS, I'm not the person to write
    Lars> such a beast.  So perhaps somebody else feels the call?

I do.  Something like this has been on my wish list for awhile now.
What I'm envisioning is something along the lines of a bookmark group.
It's a virtual group in the sense that it has no articles of its own,
only pointers to articles.

Interaction with it would be either manual addition of articles just
like G v adds new nntp groups to a virtual group, or a query mode
which runs along the lines of Kai's suggestion and is analogous to
ephemeral nnkiboze groups.  To be done right, access to the articles
would be through standard Gnus backends (one each per method).

The specific access methods I've been considering were Glimpse (if
exmh can interface to Glimpse, so should Gnus) and http/Dejanews.
WAIS, I believe, would fit right in.

The reason I strongly believe that access should be done from
something higher level than just a raw interface is to facilitate
research (by retaining a trail back to the original, and allowing for
arbitrary sources of data), and resource usage (minimize copying to
local storage when unnecessary).

I don't see this as adding a tremendous amount of code if there were
the concept of a pointer to an article in the Gnus core -- the backend
interface functions operate on the *Article* buffer right now, which
is too restrictive.  Conceptually, a pointer in this context is no
different than a URL.

My apologies if this explanation is unclear.  It'll be easier to
use than explain.
-- 
steve@miranova.com baur

Re: New features + feature freeze?

[Lars Magne Ingebrigtsen]

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

> I could turn on threading at this point but that takes quite some
> time.  Turning off threading again also takes quite some time.  WIBNI
> there would be some smaller granularity for threading, such as a way
> of gathering the current thread (ie the thread containing the current
> message)?  

Actually, that's not only possible -- it's trivial.  It's just a call
to `gnus-rebuild-thread' with a small wrapper around.  I've added it
to the todo list.

> And then there's this totally cool Information Retrieval feature:
> Devise some useful way of displaying any message at all.  Here's the
> setting:  Suppose I use WAIS (freeWAIS-sf, in particular) to index my
> Mail subdirectory (containing nnml groups).  I can then run a
> waissearch program which gives me a list of results.

I think that would require writing an nnwais (or something) backend.
Since I don't use WAIS, I'm not the person to write such a beast.  So
perhaps somebody else feels the call?

-- 
Home is where the cat is.

Re: New features + feature freeze?

[Steven L. Baur]

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

    Lars> I've been whittling away on the todo list, and it's now down
    Lars> to only 75 remaining items.  :-) At this rate, they may all
    Lars> be done by New Year.

    Lars> So perhaps there should be a new feature freeze in January
    Lars> so that we can get September working reliably.  Two months
    Lars> beta, and then we should have Gnus 5.2 ready for general
    Lars> usage Marchish?

Sounds good.  At this point I'd rather see all the ``old'' features
work reliably (NOCEM, a port of customize to XEmacs, and Gnus Daemon
come to mind) before adding more stuff.

Speaking of testing and old features, I've noticed a fair number of
questions regarding usage and problems with Gnus and foreign servers.
Is there anyone who can donate NNTP access to allow Gnus testing on
this?  I'd like to test with another NNTP server, but won't have
access to another one until at least mid '96.

    Lars> (I probably shouldn't say this, but...)  If you have ideas
    Lars> for anything neat that you think definitely should be in
    Lars> Gnus, you should probably speak up soon(ish), or it'll have
    Lars> to wait until April.

Since XEmacs has builtin sound support, it would be kind of nice to
have sound effects.  A toilet flushing when deleting articles, the
sound of a flyswatter striking when gnus-summary-mail-nastygram is
sending a message, the sound of letters being dropped into a mail box
when incoming mail arrives, etc.  :-)

    Lars> To take a look at the current (sort of; I've now shaved off
    Lars> 20 items) todo list, point your Web Thing to
    Lars> <URL:http://www.ifi.uio.no/~larsi/sgnus/todo>.

Not on your list:
* Gnus should be able to grok XHDR (I should have code to give you
  for this ready by this weekend)

* If we can't have any native Gnus support for color in the *Group*
  buffer, how about adding hooks to gnus-group-insert-group-line and
  gnus-group-update-group-line so that it can be added without hacking
  Gnus source?

* Tm MIME integration is incomplete at this time.
+ tm-edit doesn't have a buffer menu in mail mode by default
+ News Header hiding looks broken in tm-view
+ The last time I checked, C-c C-x C-z in a *news* post buffer was an
  unwise thing to do

* Customize has to be ported to XEmacs, or some better method of
  customizing colors needs to be added.

(Documentation)
* All hook functions need some documentation.  At the minimum, there
  should be a list of variables that can be safely used in that hook.

* All user callable gnus internal functions need to be at least
  enumerated, and the calling interface needs to be frozen at some
  point too.  It's difficult to customize and extend Gnus when it's a
  rapidly moving target.

-- 
steve@miranova.com baur

Re: New features + feature freeze?

[守岡 知彦 / MORIOKA Tomohiko]

>>>>> In <m2enu7gejv.fsf@diana.miranova.com>
>>>>>	steve@miranova.com (Steven L. Baur) wrote:

>> * Tm MIME integration is incomplete at this time.
>> + tm-edit doesn't have a buffer menu in mail mode by default

  This is my setting mistake. It is fixed in tm 7.35.

>> + News Header hiding looks broken in tm-view

  It is fixed in tm 7.35.

>> + The last time I checked, C-c C-x C-z in a *news* post buffer was an
>>   unwise thing to do

  It is not solved, sorry.

-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
------- I protest resumption of French and Chinese nuclear testing.---

Re: New features + feature freeze?

[Wes Hardaker]

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


steve@miranova.com (Steven L. Baur) writes:

|> Speaking of testing and old features, I've noticed a fair number of
|> questions regarding usage and problems with Gnus and foreign servers.
|> Is there anyone who can donate NNTP access to allow Gnus testing on
|> this?  I'd like to test with another NNTP server, but won't have
|> access to another one until at least mid '96.

Actually, I read news from two servers.  Generally, the support is
pretty good, after I figured out which variables I had to play with to
get it to check the servers at startup.  I also have to authenticate
into the remote server and I don't into my local server.  I wrote a
function to handle multiple authentication and submitted it to this
list a month ago or so, but since it never made it into the package,
I'll submit it again below.

The variables you need to play with are the following:  

(setq gnus-check-new-newsgroups '(
	; if you uncomment this it checks the local server twice
	;(nntp "news") 
	(nntp "other.news.server")))

If you don't do this, it doesn't check for new newsgroups on the
remote server.  This should probably be documented somewhere.  I
thought I set another variable to tell Gnus to check for new news as
well, since I didn't think it did it automatically, but I can't find
the varible in my .gnus file, so I may be dreaming.  Normally, my news
groups from the remote server show up with '*'s next to them (as
opposed to the number of un-read messages) until I set this
variable...  Hmm....  However, my remote server has been down the last
few days, so I can't test anything either right now.  Sigh...

Wes



[-- Attachment #2: mygnus-auth.el --]
[-- Type: application/octet-stream, Size: 1511 bytes --]

;;;
;;; My hacks...  sending authentication for different servers.
;;;
(add-hook 'nntp-server-opened-hook 'nntp-send-authinfo-from-alist)  ; support auth.
(defvar nntp-auth-alist nil
  "An alist containing a list of servers (and optionally a \"default\" listing)
to use as the authentication info.  Each matching entry should be a list 
holding the user name to authenticate with and optionally a password.  If the 
\"default\" value is not specified, no authentication is done for non-matching
server names.  If a password is not found, the user will be prompted for one at 
run time.

E.G.
 (setq nntp-auth-alist
      '((\"server.somewhere\" . (\"user\" \"pass\"))
        (\"default\" . (\"default user\" \"default pass\"))))")

(defun nntp-send-authinfo-from-alist ()
  "Send the AUTHINFO to the nntp server.
This function is supposed to be called from `nntp-server-opened-hook'.
It matches the server name in the variable nntp-auth-alist and pulls from the
list a user and an optional password to use when authenticating to a server.  
The alist may also contain a value of \"default\" to use by default."
  (let ((auth-info (or (assoc nntp-address nntp-auth-alist)
		       (assoc "default" nntp-auth-alist))))
    (if auth-info
	(progn
	  (nntp-send-command "^.*\r?\n" "AUTHINFO USER" (nth 1 auth-info))
	  (nntp-send-command "^.*\r?\n" "AUTHINFO PASS"
	   (if (nth 2 auth-info)
	       (nth 2 auth-info)
	     (read-string (format "pass for %s/%s:" (nth 0 auth-info)
					(nth 1 auth-info))))
	  )))))

Re: New features + feature freeze?

[Lars Magne Ingebrigtsen]

Wes Hardaker <hardaker@ece.ucdavis.edu> writes:

> (setq gnus-check-new-newsgroups '(
> 	; if you uncomment this it checks the local server twice
> 	;(nntp "news") 
> 	(nntp "other.news.server")))
> 
> If you don't do this, it doesn't check for new newsgroups on the
> remote server.  This should probably be documented somewhere. 

It is documented in the manual, even though I had to dig a bit to find
it:

----
This variable can also be a list of select methods.  If so, Gnus will
issue an @code{ask-server} command to each of the select methods, and
subscribe them (or not) using the normal methods. 
----

As for the multiple authinfo thingie -- I don't know how generally
useful that would be.  Some servers use AUTHINFO GENERIC, some use
plain AUTHINFO; some systems have the password in a special file, and
so on.  So I think it might be better if people just stick an
appropriate value for `nntp-server-opened-hook' in each of their
virtual server definitions.

-- 
Home is where the cat is.

Re: New features + feature freeze?

[Lars Magne Ingebrigtsen]

steve@miranova.com (Steven L. Baur) writes:

> Sounds good.  At this point I'd rather see all the ``old'' features
> work reliably (NOCEM, a port of customize to XEmacs, and Gnus Daemon
> come to mind) before adding more stuff.

Well -- much of the code I've added to September I haven't even given
a cursory run-through.  ("Hey, it compiles!  Ship it!")  NoCeM, group
bubbling, Gnus Daemon (and many other things) are among those untested
items...  For now I find it more exciting to write than to test.
There'll be time enough for that when the feature freeze sets in, I
think. 

> Speaking of testing and old features, I've noticed a fair number of
> questions regarding usage and problems with Gnus and foreign servers.
> Is there anyone who can donate NNTP access to allow Gnus testing on
> this?  I'd like to test with another NNTP server, but won't have
> access to another one until at least mid '96.

What I usually do when I want to test two (or more) nntp servers is
that I just set up a couple of nntp proxies that all connect to the
nntp server I normally use.

> Since XEmacs has builtin sound support, it would be kind of nice to
> have sound effects.  A toilet flushing when deleting articles, the
> sound of a flyswatter striking when gnus-summary-mail-nastygram is
> sending a message, the sound of letters being dropped into a mail box
> when incoming mail arrives, etc.  :-)

Heh.  I kinda like that idea.  It's so... *kinky*.  An Emacs package
that makes noise.

> * If we can't have any native Gnus support for color in the *Group*
>   buffer, how about adding hooks to gnus-group-insert-group-line and
>   gnus-group-update-group-line so that it can be added without hacking
>   Gnus source?

Well, I think we should add native Gnus highlighting in the group
buffer.  Perhaps just do it much the same way as highlighting in the
summary buffer?  The same sort of structures?

> + The last time I checked, C-c C-x C-z in a *news* post buffer was an
>   unwise thing to do

`suspend-emacs'?  In what way is that unwise?

> (Documentation)
> * All hook functions need some documentation.  At the minimum, there
>   should be a list of variables that can be safely used in that hook.

You mean variables that are dynamically bound when the hook is called?
Or global variables that have meaningful values when the hook is
called?  I don't want to document the dynamical variables since they
are likely to change, and listing all global variables for each hook
seems a bit excessive.  :-)

> * All user callable gnus internal functions need to be at least
>   enumerated, and the calling interface needs to be frozen at some
>   point too.  It's difficult to customize and extend Gnus when it's a
>   rapidly moving target.

All internal functions are user callable, no?  I'm slowly adding
documentation strings to all Gnus functions.  (I'm not doing this
systematically -- every time I look & fix a function I just add
documentation.)  Anyways, I've been keeping the interface to the
interactive functions pretty frozen.  (I've mostly been adding new
optional parameters.)  I still think it's a bit too early to promise
that I won't change any internal functions.  I just don't feel that
Gnus is mature enough to say "This is The Way."  I make lots of stupid
decisions that I later regret...

-- 
Home is where the cat is.

Re: New features + feature freeze?

[Steven L. Baur]

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

    sb> ... I'd like to test with another NNTP server, but won't have
    sb> access to another one until at least mid '96.

    Lars> What I usually do when I want to test two (or more) nntp
    Lars> servers is that I just set up a couple of nntp proxies that
    Lars> all connect to the nntp server I normally use.

I didn't realize that would have the same effect, but that sounds
reasonable.  Now where does one get an NNTP proxy?

I found two references from Dejanews:
	ftp://etlport.etl.go.jp/pub/ccipr/DeleGate/delegate2.9.7.tar.gz
	ftp://ftp.cs.cmu.edu/
		(misc/dnntpd/dnntpd.tar.Z)

(The CMU site behaves wierdly.  It will not allow an argument to cd
beginning with a slash, so do a manual ``cd misc/dnntpd'' to reference
it manually).

    sb> + The last time I checked, C-c C-x C-z in a *news* post buffer
    sb> was an unwise thing to do

    Lars> `suspend-emacs'?  In what way is that unwise?

That key sequence is bound to 

mime-editor/exit:
Translate the tagged MIME message into a MIME compliant message.
With no argument encode a message in the buffer into MIME, otherwise
just return to previous mode.

When the news article is posted, Gnus article post-editing-processing
is bypassed and does not have the opportunity to process Fcc's, add
From:, Organization:, etc.

So long as the initial prompt is ignored, and C-c C-c is used to exit,
everything works great.

    sb> (Documentation) All hook functions need some documentation.
    sb> At the minimum, there should be a list of variables that can
    sb> be safely used in that hook.

    Lars> You mean variables that are dynamically bound when the hook
    Lars> is called?

Yes, as illustrated below.

    Lars> Or global variables that have meaningful values
    Lars> when the hook is called?  I don't want to document the
    Lars> dynamical variables since they are likely to change, and
    Lars> listing all global variables for each hook seems a bit
    Lars> excessive.  :-)

If they are likely to change, then they should not be designated as
``user callable'' and documented as such (or at all for that matter).

As an example, I'm looking at the nnml-prepare-save-mail-hook I
recently wrote.

This particular hook is called after the destination nnml folders have
been selected.  They reside in the group-art alist dynamic variable.
This should be documented.

Similarly, the dynamic variable ``group'' should be documented in
conjunction with the nnmail-prepare-incoming-hook.

Basically there are usually one or two variables that contain
information that a hook function could make good use of.  These should
be listed.

Gnus-point-at-bol and gnus-point-at-eol are two good examples of
functions that should be listed as user callable.

Gnus-get-newsgroup-headers-xover is an example of an internal Gnus
function that probably shouldn't be called by a user.

-- 
steve@miranova.com baur

Re: New features + feature freeze?

[Lars Magne Ingebrigtsen]

steve@miranova.com (Steven L. Baur) writes:

> I didn't realize that would have the same effect, but that sounds
> reasonable.  Now where does one get an NNTP proxy?

<URL:http://www.ifi.uio.no/~larsi/ding-various/tcpgate> is a perl
script I've used for that...

> As an example, I'm looking at the nnml-prepare-save-mail-hook I
> recently wrote.
> 
> This particular hook is called after the destination nnml folders have
> been selected.  They reside in the group-art alist dynamic variable.
> This should be documented.

Well, that's a implementation detail that's likely to change.

> Similarly, the dynamic variable ``group'' should be documented in
> conjunction with the nnmail-prepare-incoming-hook.

And that one too.  Requiring that all dynamic variables keep their
names when there is a hook call further down would be a real pain (for
me). 

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

Re: New features + feature freeze?

[Sten Drescher]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> said:

LMI> (I probably shouldn't say this, but...)  If you have ideas for
LMI> anything neat that you think definitely should be in Gnus, you
LMI> should probably speak up soon(ish), or it'll have to wait until
LMI> April.

	1) A better algorithm for adopting orphaned threads.  In a
thread where one poster (A) has a news agent that does references, and
one (B) does not, I often see threads which were posted in the order:

A1
  B1
    A2
      B2
        A3
          B3

but the adoption process ends up with:

B3
  B2
    A3
  B1
    A2
  A1

even when A1 has the lowest article number.  At the very least, the
lowest-numbered article should become the adoptive root.

	2) Expiring temporary scores.  "But we already have that!", you
say.  Well, yes, in one way - if a temporary score is unused, it
vanishes.  But if it gets used, the date field is updated, so it
persists.  I want temporary scores which expire n days after they are
created, whether or not they are used.  I'd prefer that this be a
score-by-score option, or, at worst, a SCORE-file-by-SCORE-file option,
but I'd settle for a global toggle.

-- 
#include <disclaimer.h>				/* Sten Drescher */
To get my PGP public key, send me email with your public key and
	Subject: PGP key exchange
Key fingerprint =  90 5F 1D FD A6 7C 84 5E  A9 D3 90 16 B2 44 C4 F3

Re: New features + feature freeze?

[Lars Magne Ingebrigtsen]

Sten Drescher <stend@cris.com> writes:

> but the adoption process ends up with:
> 
> B3
>   B2
>     A3
>   B1
>     A2
>   A1
> 
> even when A1 has the lowest article number.  At the very least, the
> lowest-numbered article should become the adoptive root.

Threads are sorted before they are gathered, so I don't quite see how
this happens...  unless you have taken `gnus-article-sort-by-number'
out of `gnus-article-sort-functions'.

> 	2) Expiring temporary scores.  "But we already have that!", you
> say.  Well, yes, in one way - if a temporary score is unused, it
> vanishes.  But if it gets used, the date field is updated, so it
> persists. 

Ok; I've added this to the todo list.  I'll go for a variable to
toggle the behavior.

-- 
Home is where the cat is.

Re: New features + feature freeze?

[Sten Drescher]

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

LMI> Sten Drescher <stend@cris.com> writes:
>> but the adoption process ends up with:
>> 
>> B3
>>  B2
>>   A3
>>  B1
>>   A2
>>  A1
>> 
>> even when A1 has the lowest article number.  At the very least, the
>> lowest-numbered article should become the adoptive root.

LMI> Threads are sorted before they are gathered, so I don't quite see
LMI> how this happens...  unless you have taken
LMI> `gnus-article-sort-by-number' out of `gnus-article-sort-functions'.

	Nope, I've never touched it.  I do, however, use
gnus-thread-sort-functions:

(setq gnus-thread-sort-functions '(gnus-thread-sort-by-date
				   gnus-thread-sort-by-total-score))

	But I would hope that this would happen _after_ the thread is
gathered.  At any rate, I see the behavior I described, and it's really
annoying. ;)  Speaking of which...

3) Mark unread but not originally selected articles as read when they
are read.  What I mean is this: when entering a large newsgroup, I
usually only select the last 200 articles.  Well, often those articles
follow-up to unread articles that I haven't read yet, and, since I use
gnus-fetch-old-headers, these parents are marked as O.  Fair enough.
Often I read these articles so that I can see the entire context.  Well,
the article remains O, not R, so when I go into the group again, reading
the older articles that I didn't fetch the previous time, I run into the
article again.  I think that there needs to be a distinction made
(internally) between old-read and old-unread messages, and mark
old-unread messages as read whewn they are.

-- 
#include <disclaimer.h>				/* Sten Drescher */
To get my PGP public key, send me email with your public key and
	Subject: PGP key exchange
Key fingerprint =  90 5F 1D FD A6 7C 84 5E  A9 D3 90 16 B2 44 C4 F3

Re: New features + feature freeze?

[Lars Magne Ingebrigtsen]

Sten Drescher <stend@cris.com> writes:

> LMI> Threads are sorted before they are gathered, so I don't quite see
> LMI> how this happens...  unless you have taken
> LMI> `gnus-article-sort-by-number' out of `gnus-article-sort-functions'.
> 
> 	Nope, I've never touched it.  I do, however, use
> gnus-thread-sort-functions:
> 
> (setq gnus-thread-sort-functions '(gnus-thread-sort-by-date
> 				   gnus-thread-sort-by-total-score))

Whoops, sorry -- I meant `gnus-thread-sort-functions'.  You should
stick `gnus-article-sort-by-number' in there somewhere if you want to
avoid having newer articles coming before older articles.  (Sorting by
date isn't very reliable -- many articles have highly bogus dates.)

> 3) Mark unread but not originally selected articles as read when they
> are read.  What I mean is this: when entering a large newsgroup, I
> usually only select the last 200 articles.  Well, often those articles
> follow-up to unread articles that I haven't read yet, and, since I use
> gnus-fetch-old-headers, these parents are marked as O.  

Ooh.  Bugola.  I'll add fixing it to the todo list.

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

Re: New features + feature freeze?

[Sten Drescher]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> said:

>> 3) Mark unread but not originally selected articles as read when they
>> are read.  What I mean is this: when entering a large newsgroup, I
>> usually only select the last 200 articles.  Well, often those
>> articles follow-up to unread articles that I haven't read yet, and,
>> since I use gnus-fetch-old-headers, these parents are marked as O.

LMI> Ooh.  Bugola.  I'll add fixing it to the todo list.

	Well, I would prolly still want them marked as old, since they
aren't in the last n articles, but they should become marked as read
rather than old if they are read.

-- 
#include <disclaimer.h>				/* Sten Drescher */
To get my PGP public key, send me email with your public key and
	Subject: PGP key exchange
Key fingerprint =  90 5F 1D FD A6 7C 84 5E  A9 D3 90 16 B2 44 C4 F3
Junk email is NOT appreciated.  If I want to buy something, I'll find
you.

Re: New features + feature freeze?

[Christopher Davis]

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

 LMI> Threads are sorted before they are gathered, so I don't quite see how
 LMI> this happens...  unless you have taken `gnus-article-sort-by-number'
 LMI> out of `gnus-article-sort-functions'.

Well, here's how it usually breaks for me (note that I use 5.0.12 and
gnus-summary-make-false-root set to 'none, choosing to gather the threads
but not adopt, but the same situation applies):

original post
  followup by higher-scoring poster with broken newsreader (no references)

since I sort by number *and score*, the higher-scoring poster's Re:
article will appear before the rest of the thread (since it sorted first
before the gathering), like this:

Re: blah (high scoring poster)
blah
 Re: blah (posters with working References)
  [etc]

Re: New features + feature freeze?

[Sten Drescher]

Christopher Davis <ckd@loiosh.kei.com> said:

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> said:

LMI> Threads are sorted
LMI> before they are gathered, so I don't quite see how this happens...
LMI> unless you have taken `gnus-article-sort-by-number' out of
LMI> `gnus-article-sort-functions'.

ckd> Well, here's how it usually breaks for me 

[...]

ckd> since I sort by number *and score*, the higher-scoring poster's Re:
ckd> article will appear before the rest of the thread (since it sorted
ckd> first before the gathering), like this:

	That sounds like that's it, cause I do the same thing (I changed
sort-by-date to sort-by-number, and it still happens).  This is a Bad
Thing.  The threads need to be gathered first, then sorted, since
gnus-thread-sort-functions are supposed to be sorting threads, not
articles within threads.

-- 
#include <disclaimer.h>				/* Sten Drescher */
To get my PGP public key, send me email with your public key and
	Subject: PGP key exchange
Key fingerprint =  90 5F 1D FD A6 7C 84 5E  A9 D3 90 16 B2 44 C4 F3
Junk email is NOT appreciated.  If I want to buy something, I'll find
you.

Re: New features + feature freeze?

[Lars Magne Ingebrigtsen]

Sten Drescher <stend@cris.com> writes:

> The threads need to be gathered first, then sorted, since
> gnus-thread-sort-functions are supposed to be sorting threads, not
> articles within threads.

Yes, I agree.  Hmn.  Or at least I think I do.  Can't somebody
convince me that this is a bad idea?  This sounds like Real Work
fixing this, and I certainly don't like Real Work.  :-)

-- 
(a red leaf that falls from the purple tree)
    Lars Magne Ingebrigtsen * larsi@ifi.uio.no

Re: New features + feature freeze?

[Christopher Davis]

SD> == Sten Drescher <stend@cris.com>
LMI> == Lars Magne Ingebrigtsen <larsi@ifi.uio.no>

 SD> The threads need to be gathered first, then sorted, since
 SD> gnus-thread-sort-functions are supposed to be sorting threads, not
 SD> articles within threads.

 LMI> Yes, I agree.  Hmn.  Or at least I think I do.  Can't somebody
 LMI> convince me that this is a bad idea?  This sounds like Real Work
 LMI> fixing this, and I certainly don't like Real Work.  :-)

Maybe the gathering could be something that could be done from within
gnus-thread-sort-functions, so that we could do something like:

(setq gnus-thread-sort-functions '(
				   gnus-thread-sort-by-number
				   gnus-thread-gather
				   gnus-thread-sort-by-total-score
				   ))

because I want the orphaned articles sorted in arrival order within each
thread, but I don't want them sorted by score within each thread...

Re: New features + feature freeze?

[Lars Magne Ingebrigtsen]

Christopher Davis <ckd@loiosh.kei.com> writes:

> Maybe the gathering could be something that could be done from within
> gnus-thread-sort-functions, so that we could do something like:
> 
> (setq gnus-thread-sort-functions '(
> 				   gnus-thread-sort-by-number
> 				   gnus-thread-gather
> 				   gnus-thread-sort-by-total-score
> 				   ))
> 
> because I want the orphaned articles sorted in arrival order within each
> thread, but I don't want them sorted by score within each thread...

That would be a possibility, but it would be lots more work.  (In
short -- all the sorting functions rely on the threads they sort being
"real" threads and not gathered threads.)

September 0.27 sorts all gathered threads (internally) over article
number, which is the arrival order.

-- 
   Lars Magne Ingebrigtsen * larsi@ifi.uio.no
      (a red leaf that falls from the purple tree)

Re: New features + feature freeze?

[Sten Drescher]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> said:

LMI> Sten Drescher <stend@cris.com> writes:
>> The threads need to be gathered first, then sorted, since
>> gnus-thread-sort-functions are supposed to be sorting threads, not
>> articles within threads.

LMI> Yes, I agree.  Hmn.  Or at least I think I do.  Can't somebody
LMI> convince me that this is a bad idea?  This sounds like Real Work
LMI> fixing this, and I certainly don't like Real Work.  :-)

	It should be fixed, because you are apparently using
gnus-thread-sort-functions as gnus-article-sort-functions.  It
confuses me as to how you can sort threads by their total score before
the threads have been gathered, since the threads need to be gathered
before you know what goes together for the total score.

-- 
#include <disclaimer.h>				/* Sten Drescher */
Unsolicited email advertisements will be proofread for a US$100 fee.

Re: New features + feature freeze?

[Yair Friedman]

>>>>> "SD" == Sten Drescher <stend@grendel.texas.net> writes:

SD> Lars Magne Ingebrigtsen <larsi@ifi.uio.no> said:
LMI> Sten Drescher <stend@cris.com> writes:
>>> The threads need to be gathered first, then sorted, since
>>> gnus-thread-sort-functions are supposed to be sorting threads, not
>>> articles within threads.

LMI> Yes, I agree.  Hmn.  Or at least I think I do.  Can't somebody
LMI> convince me that this is a bad idea?  This sounds like Real Work
LMI> fixing this, and I certainly don't like Real Work.  :-)

SD> It should be fixed, because you are apparently using
SD> gnus-thread-sort-functions as gnus-article-sort-functions.  It
SD> confuses me as to how you can sort threads by their total score before
SD> the threads have been gathered, since the threads need to be gathered
SD> before you know what goes together for the total score.

There should be different methods to sort threads and to sort orphan
articles within a thread.

If it is possible I would like to suggest another way of threading.
My definition of a thread is that two articles are in the same thread
if they have at least one common article in the References header,
even if this article is not in the server any more.
----------------------------------------------------------------------------
Yair I. Friedman            yair@cs.huji.ac.il            yair@HUJICS.BITNET

A human being should be able to change a diaper, plan an invasion, butcher a
hog, conn a ship, design a building, write a sonnet, balance accounts, build
a wall, set a bone, comfort the dying,  take orders, give orders, cooperate,
act alone,  solve equations, analyze a new problem,  pitch manure, program a
computer, cook a tasty meal, fight efficiently, die gallantly.
Specialization is for insects.                         -- Robert A. Heinlein
----------------------------------------------------------------------------

 

Re: New features + feature freeze?

[Lars Magne Ingebrigtsen]

Yair Friedman <yair@cs.huji.ac.il> writes:

> If it is possible I would like to suggest another way of threading.
> My definition of a thread is that two articles are in the same thread
> if they have at least one common article in the References header,
> even if this article is not in the server any more.

This is included in September 0.27:

gnus-summary-thread-gathering-function's value is gnus-gather-threads-by-subject

Documentation:
Function used for gathering loose threads.
There are two pre-defined functions: `gnus-gather-threads-by-subject',
which only takes Subjects into consideration; and
`gnus-gather-threads-by-references', which compared the References
headers of the articles to find matches.

-- 
   Lars Magne Ingebrigtsen * larsi@ifi.uio.no
      (a red leaf that falls from the purple tree)

Re: New features + feature freeze?

[Per Abrahamsen]

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

LMI> gnus-summary-thread-gathering-function's value is gnus-gather-threads-by-subject

LMI> Documentation:
LMI> Function used for gathering loose threads.
LMI> There are two pre-defined functions: `gnus-gather-threads-by-subject',
LMI> which only takes Subjects into consideration; and
LMI> `gnus-gather-threads-by-references', which compared the References
LMI> headers of the articles to find matches.

What if you want both?  I'd like it to gather as much as possible
using references, and then gather what is left using subject.

Re: New features + feature freeze?

[Greg Stark]

Per said:
> What if you want both?  I'd like it to gather as much as possible
> using references, and then gather what is left using subject.

I second this.  I've been meaning to post about this for a while.  I think the
idea of threading is to minimize the number of distinct threads for me to deal
with.  If there are two threads with the same topic then it's been defeated.
So I want it to use references headers to get the threads right whenever
possible, but when someone's broken reader messes up it should go ahead and
try to correct by looking at the subject lines.

Sten said:
> This is a Bad Thing.  When I use gnus-sort-by-total-score, I
> want the total score of the entire thread used, whether 'real' with
> references or gathered orphaned articles.

I second this as well.  Actually We'll have to thing more about what it means
to sort and score threads.  Maybe the right thing to do is to sort children of
the same article according to the the cumulative score (using
gnus-thread-score-function) of all their children. Then sort the thread roots
the same way.  However, I don't think this actually provides much benefit; I'm
not sure if it's worth it.

--
greg

Re: New features + feature freeze?

[Lars Magne Ingebrigtsen]

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

> LMI> gnus-summary-thread-gathering-function's value is gnus-gather-threads-by-subject

> What if you want both?  I'd like it to gather as much as possible
> using references, and then gather what is left using subject.

Hmn.  I'm not sure how much of a gain that would be, actually.  The
problem with gathering by References is that many articles have
mangled (or missing) References headers, so we get too many root-less
threads.  The problem with gathering by Subject is that unrelated
threads with the same subject get gathered into one big thread.
Combining these two methods would just, like, produce biiig threads.  

On the other hand, perhaps some people would like that?  

(Also, gathering is done on thread roots, so it's difficult to predict
how this behaves when threads change subject...  Hmn.)

-- 
Home is where the cat is.

Re: New features + feature freeze?

[Lars Magne Ingebrigtsen]

Sten Drescher <stend@grendel.texas.net> writes:

> >> The threads need to be gathered first, then sorted, since
> >> gnus-thread-sort-functions are supposed to be sorting threads, not
> >> articles within threads.
> 
> LMI> Yes, I agree.  Hmn.  Or at least I think I do.  Can't somebody
> LMI> convince me that this is a bad idea?  This sounds like Real Work
> LMI> fixing this, and I certainly don't like Real Work.  :-)
> 
> 	It should be fixed, because you are apparently using
> gnus-thread-sort-functions as gnus-article-sort-functions. 

Uhm.  I don't quite know what you mean --
`gnus-article-sort-functions' is used only when not using a threaded
display. 

But I have added sorting of gathered threads now. 

> It confuses me as to how you can sort threads by their total score
> before the threads have been gathered, since the threads need to be
> gathered before you know what goes together for the total score.

Well -- gathered threads don't have a score, really.  

-- 
   Lars Magne Ingebrigtsen * larsi@ifi.uio.no
      (a red leaf that falls from the purple tree)

Re: New features + feature freeze?

[Sten Drescher]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> said:

LMI> Sten Drescher <stend@grendel.texas.net> writes:
>> >> The threads need to be gathered first, then sorted, since >>
>> gnus-thread-sort-functions are supposed to be sorting threads, not
>> >> articles within threads.
>> 
LMI> Yes, I agree.  Hmn.  Or at least I think I do.  Can't somebody
LMI> convince me that this is a bad idea?  This sounds like Real Work
LMI> fixing this, and I certainly don't like Real Work.  :-)

>>  It should be fixed, because you are apparently using
>> gnus-thread-sort-functions as gnus-article-sort-functions.

LMI> Uhm.  I don't quite know what you mean --
LMI> `gnus-article-sort-functions' is used only when not using a
LMI> threaded display.

	That's the problem, then!  One of the solutions would be to
apply gnus-article-sort-functions, then gather threads, then apply
gnus-group-sort-functions.

LMI> But I have added sorting of gathered threads now.

	This should solve the problem, too (; .

>> It confuses me as to how you can sort threads by their total score
>> before the threads have been gathered, since the threads need to be
>> gathered before you know what goes together for the total score.

LMI> Well -- gathered threads don't have a score, really.

	This is a Bad Thing.  When I use gnus-sort-by-total-score, I
want the total score of the entire thread used, whether 'real' with
references or gathered orphaned articles.

-- 
#include <disclaimer.h>				/* Sten Drescher */
1973 Steelers    About Three Bricks Shy of a Load    1994 Steelers
1974 Steelers         And the Load Filled Up         1995 Steelers?
Unsolicited email advertisements will be proofread for a US$100 fee.

Re: New features + feature freeze?

[Lars Magne Ingebrigtsen]

Sten Drescher <stend@grendel.texas.net> writes:

> LMI> Uhm.  I don't quite know what you mean --
> LMI> `gnus-article-sort-functions' is used only when not using a
> LMI> threaded display.
> 
> 	That's the problem, then!  One of the solutions would be to
> apply gnus-article-sort-functions, then gather threads, then apply
> gnus-group-sort-functions.

That's not possible with the current implementation.  Articles are
threaded first, then all the rest is done.  (Turning off threading
doesn't really switch threading off -- the threads are just not
displayed as such.)

> LMI> Well -- gathered threads don't have a score, really.
> 
> 	This is a Bad Thing.  When I use gnus-sort-by-total-score, I
> want the total score of the entire thread used, whether 'real' with
> references or gathered orphaned articles.

That's ok for that sorting predicate.  But how about, say,
`gnus-thread-sort-by-author'?  How are the sorting functions supposed
to sort a gathered thread, when a gathered thread doesn't really have
an author in the root?

-- 
Home is where the cat is.

Re: New features + feature freeze?

[Yair Friedman]

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



LMI> Well -- gathered threads don't have a score, really.
>> 
>> This is a Bad Thing.  When I use gnus-sort-by-total-score, I
>> want the total score of the entire thread used, whether 'real' with
>> references or gathered orphaned articles.

LMI> That's ok for that sorting predicate.  But how about, say,
LMI> `gnus-thread-sort-by-author'?  How are the sorting functions supposed
LMI> to sort a gathered thread, when a gathered thread doesn't really have
LMI> an author in the root?

gnus-thread-sort-by-author is the only sorting function that is
meaningless, who sort by author on a threaded reader? if you want to
sort by author you usually disable threading, and then sort.  Sort by
date, number and subject, is applying the sort on threads roots, sort
by score is realy sort by total score.
--
Yair.

Re: New features + feature freeze?

[Lars Magne Ingebrigtsen]

Yair Friedman <yair@cs.huji.ac.il> writes:

> LMI> That's ok for that sorting predicate.  But how about, say,
> LMI> `gnus-thread-sort-by-author'?  How are the sorting functions supposed
> LMI> to sort a gathered thread, when a gathered thread doesn't really have
> LMI> an author in the root?
> 
> gnus-thread-sort-by-author is the only sorting function that is
> meaningless, who sort by author on a threaded reader? if you want to
> sort by author you usually disable threading, and then sort.  Sort by
> date, number and subject, is applying the sort on threads roots, sort
> by score is realy sort by total score.

The same goes with sorting by date, number and subject as with author.
Parts of a gathered thread do not necessarily have the same subject,
and they certainly do not have the same date and number.  So the
question remains -- what subject, date, author, and number are one
supposed to use when sorting gathered threads?

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

Re: New features + feature freeze?

[Yair Friedman]

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


LMI> Yair Friedman <yair@cs.huji.ac.il> writes:
LMI> That's ok for that sorting predicate.  But how about, say,
LMI> `gnus-thread-sort-by-author'?  How are the sorting functions supposed
LMI> to sort a gathered thread, when a gathered thread doesn't really have
LMI> an author in the root?
>> 
>> gnus-thread-sort-by-author is the only sorting function that is
>> meaningless, who sort by author on a threaded reader? if you want to
>> sort by author you usually disable threading, and then sort.  Sort by
>> date, number and subject, is applying the sort on threads roots, sort
>> by score is realy sort by total score.

LMI> The same goes with sorting by date, number and subject as with author.
LMI> Parts of a gathered thread do not necessarily have the same subject,
LMI> and they certainly do not have the same date and number.  So the
LMI> question remains -- what subject, date, author, and number are one
LMI> supposed to use when sorting gathered threads?

Sorting sorting by date and number should be done by the date/number
of the root, or the oldest of the orphans, for subject its either the
subject wans't changed and then it's safe to sort by the root, or the
gathering is too agressive.. as for authois, I don't knink that there
should be any gnus-thread-sort-by-author at all.
--
Yair.