Ideas for .no Gnus

Ideas for .no Gnus

[Frank Schmitt]

Hello

Now that Oort is released, I'd like to throw some ideas in, which
features I as (primarily) a user would like to see in the next Gnus:

*themes*: It would be quite cool if people could export their settings
 for the various ...-line-format variables (especially
 gnus-summary-line-format) to a file so they can easily exchange them,
 Gnus could also include some predefined sets (e.g. classic, slrn-like,
 table-format...)

*configuration wizard*: This one is AFAIK already quite high in the todo
 list of Larsi, my idea would be short questions in the minibuffer and
 an explanation of what the user is supposed to answer in the active
 buffer, but there are probably other, better ways of implementing it.

*A fix for the "Gnus doesn't recognize connection loss problem"* I
 don't really know why, but for me Gnus fails to recognize it when a
 server silently drops connection, e.g. because of a timeout. Gnus
 should really automatically recognize this and restart connection
 without the need for the user to set some mystique variables (which
 only exist for nntp and not for e.g. nnimap)

*images in summary buffer* It would be nice, if it was possible to use
 small images instead of characters for the different marks in summary
 buffer.

*cache of seen message-ids* Discussed some threads above: Some solution
 which helps synchronizing .newsrc between two Gnus which read news
 from different servers would help all those who read e.g. at home from
 a Leafnode and at work from some other news server.

*Support for xpat and xhdr* For those of us who use Gnus for reading
 news an options to send a xpat search to the news server and create a
 summary buffer with the matching articles would be nice. Quite some of
 the required work should already be done in Kai Großjohanns nnir.el.

*Leaving messages on pop server* OK, there's epop3.el but it isn't
 actively maintained as far as I know, so perhaps it would be a good
 idea to tune Gnus' pop3.el instead.

*Nicer buttons* Some of the Gnus related buttons in the button bar are
 really nice, but some really don't fit in (e.g. "mark this message as
 [un]important")

Well, I could probably think of more, but those are the ones which I'd
like most. What do you think about them and which other ideas are there?

MFG Frank

-- 
WANTED: A nice signature
REWARD: none

Re: Ideas for .no Gnus

[Josh Huber]

Frank Schmitt <usereplyto@Frank-Schmitt.net> writes:

> [snip]

> Well, I could probably think of more, but those are the ones which
> I'd like most. What do you think about them and which other ideas
> are there?

Good ideas...making configuration easier would definately be a good
thing.  I think the auto-reconnection to dropped connections is an
important thing as well.

* Proper article counts (for backends which make this possible).

* Async/background signature checking, so as to not prevent articles
from being displayed.

* More async/background behavior would be nice, but I'm not sure how
  far we can push this inside Emacs.

Those are off the top of my head, but I'm sure I'll think of more...

-- 
Josh Huber

Re: Ideas for .no Gnus

[Mike Woolley]

Josh Huber <huber@alum.wpi.edu> writes:

> * Proper article counts (for backends which make this possible).

This one is at the top of my list!

Cheers,
Mike

IMAP partial fetch (was Re: Ideas for .no Gnus)

[Zack Weinberg]

Frank Schmitt <usereplyto@Frank-Schmitt.net> writes:

> Hello
>
> Now that Oort is released, I'd like to throw some ideas in, which
> features I as (primarily) a user would like to see in the next Gnus:
...

This is the first of my two wishes:

Consider the following imap-log extract (word-wrapped, CRs removed,
and censored):

59 UID FETCH 1:150 (UID
                    RFC822.SIZE
                    BODY
                    BODY.PEEK[HEADER.FIELDS
                     (Subject From Date Message-Id References
                      In-Reply-To Xref To Newsgroups)])

# ... 149 other responses ...

* 150 FETCH (UID 150 RFC822.SIZE 351157 BODY 
             (("text" "plain" 
               ("charset" "us-ascii" "format" "flowed") NIL NIL "8bit" 647 20)
              ("application" "msword"
               ("name" "xxxxxx.doc" "x-mac-type" "42494E41"
                "x-mac-creator" "4D535744") NIL NIL "base64" 348914)
              "mixed")
      BODY[HEADER.FIELDS 
            ("Subject" "From" "Date" "Message-Id" "References"
             "In-Reply-To" "Xref" "To" "Newsgroups")]
      {253}
Message-Id: ...
Date: ...
To: ...
From: ...
Subject: ...

)
59 OK FETCH completed.
60 UID FETCH 150 BODY.PEEK[]
* 150 FETCH (UID 150 BODY[] {351157}

# ... 351157 bytes of message body here ...

The server provided Gnus enough information to know that the message
was multipart, and the second part was a large binary attachment
(application/msword, 348914 bytes).  Yet Gnus downloaded the entire
message body.  I would like Gnus to use the IMAP partial-content-
request functionality to avoid downloading undisplayed attachments
until the user asks for them with the button commands.  In this case,
issuing

60 UID FETCH 150 (BODY.PEEK[HEADER] BODY.PEEK[1])

would have resulted in a transmission of only 1837 bytes of literal
data (1190 for BODY[HEADER], 647 for BODY[1]).  I suspect that this is
a major reason why Gnus is so slow to display articles in IMAP groups
with attachments.  In the case of the message above, I didn't bother
looking at the attachment, so Gnus need not have downloaded it at all;
for messages where the user does want to look at the attachment, they
are probably more willing to accept a lengthy download delay when they
ask for the attachment to be saved, than when they ask to view the
message.

The IMAP4 BODYSTRUCTURE request will reveal the Content-Disposition
annotation for attachments, if any, which may help decide whether or
not to download them.

zw

Re: IMAP partial fetch

[Jody Klymak]

Zack Weinberg <zack@codesourcery.com> writes:

> The IMAP4 BODYSTRUCTURE request will reveal the Content-Disposition
> annotation for attachments, if any, which may help decide whether or
> not to download them.

I'll second this one.  I don't mind so much at work, but if I'm on a
dial-up my gnus session is all over if I stumble across a 1 Mb
attachment.  I have to use Pine when I dial-up now.

Cheers,  Jody

-- 
Jody Klymak                           104 Ocean Admin Bldg., OSU
mailto:jklymak@coas.oregonstate.edu   Corvallis OR, 97330

Re: IMAP partial fetch

[Lloyd Zusman]

Zack Weinberg <zack@codesourcery.com> writes:

> Frank Schmitt <usereplyto@Frank-Schmitt.net> writes:
>
>> Hello
>>
>> Now that Oort is released, I'd like to throw some ideas in, which
>> features I as (primarily) a user would like to see in the next Gnus:
> ...
>
> [ ... partial imap fetch descriibed ... ]
>
> [ ... ]
> for messages where the user does want to look at the attachment, they
> are probably more willing to accept a lengthy download delay when they
> ask for the attachment to be saved, than when they ask to view the
> message.
>
> [ ... ]

I enthusiastically add my vote for this proposal, with the following
refinement: a group-specific variable could control whether these
attachments get downloaded as part of the entire message (as is done
now), or only when the user wants to see them.  This way, different
groups could be configured differently in this regard.  A configurable,
system-wide default setting could take effect if the group-specific
variable isn't set.

I think a cool related feature would be to download the IMAP4
BODYSTRUCTURE output of a message (in some suitably formatted manner)
along with the headers.  This way, the user could view the structure of
any message from the Summary buffer, and via a dialog, could optionally
request a subset of the parts to be actually downloaded.  A keystroke in
the Summary buffer could toggle the display of this structure for any
given message.

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: IMAP partial fetch

[Kai Großjohann]

Lloyd Zusman <ljz@asfast.com> writes:

> I think a cool related feature would be to download the IMAP4
> BODYSTRUCTURE output of a message (in some suitably formatted manner)
> along with the headers.  This way, the user could view the structure of
> any message from the Summary buffer, and via a dialog, could optionally
> request a subset of the parts to be actually downloaded.  A keystroke in
> the Summary buffer could toggle the display of this structure for any
> given message.

C-d could be used as a UI for this.
-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: IMAP partial fetch

[Steinar Bang]

>>>>> Zack Weinberg <zack@codesourcery.com>:

[snip!]
> ...  I would like Gnus to use the IMAP partial-content- request
> functionality to avoid downloading undisplayed attachments until the
> user asks for them with the button commands.  

Here are Simon Josefsson's thoughts on implementation, from last
summer: 
	nntp://news.gmane.org/gmane.emacs.gnus.general/45839

Re: Ideas for .no Gnus

[Richard Hoskins]

I would like to see tight integration with Calendar, Diary, and
Todo, with an eye toward exchanging meeting/calendar information with
Notes, Evolution, and Outlook users.

-- 
Lift me down, so I can make the Earth tremble.
                                --Bucky Katt

Re: Ideas for .no Gnus

[Nevin Kapur]

Richard Hoskins <rmh@apk.net> writes:

> I would like to see tight integration with Calendar, Diary, and
> Todo, with an eye toward exchanging meeting/calendar information with
> Notes, Evolution, and Outlook users.

I think this is a great idea.

Gnus started off as a newsreader and gained mail reading capabilities.
The next evolution could be in the direction of a PIM.

-N

Re: Ideas for .no Gnus

[Steve Youngs]

|--==> "RH" == Richard Hoskins <rmh@apk.net> writes:

  RH> I would like to see tight integration with Calendar, Diary, and
  RH> Todo, 

nndiary.el

  RH> with an eye toward exchanging meeting/calendar information with
  RH> Notes, Evolution, and Outlook users.

*shudder*

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
|        XEmacs - The only _______ you'll ever need.       |
|          Fill in the blank, yes, it's THAT good!         |
|------------------------------------<youngs@xemacs.org>---|

Re: Ideas for .no Gnus

[A.J. Rossini]

Steve Youngs <youngs@xemacs.org> writes:


> |--==> "RH" == Richard Hoskins <rmh@apk.net> writes:
>
>   RH> I would like to see tight integration with Calendar, Diary, and
>   RH> Todo, 
>
> nndiary.el
>
>   RH> with an eye toward exchanging meeting/calendar information with
>   RH> Notes, Evolution, and Outlook users.
>
> *shudder*

Come on, it's not that bad -- it would be great if GNUS replaced my
use of Korganizer (it's close, I just need to be able to sync nndiary
with my palm and the real (emacs) calendar, BBDB already syncs, and as
far as configuration issues go, with nndiary, well it's gnus, right? 

Even if nndiary did sync, it still would be nice to have nndiary use
the "standard" calendar-mail-meeting-request protocol.

Besides, cooperation is double-plus good, right?  We can use microsoft
kerberos as a stellar model for the right paradigm to follow...

best,
-tony

-- 
A.J. Rossini rossini@u.washington.edu http://software.biostat.washington.edu/ 
Biostatistics, U Washington and Fred Hutchinson Cancer Research Center

FHCRC:Tu: 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email 
UW  : Th: 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX 

CONFIDENTIALITY NOTICE: This e-mail message and any attachments may be
confidential and privileged. If you received this message in error,
please destroy it and notify the sender. Thank you.

Re: Ideas for .no Gnus

[Richard Hoskins]

Steve Youngs <youngs@xemacs.org> writes:

> |--==> "RH" == Richard Hoskins <rmh@apk.net> writes:

>   RH> with an eye toward exchanging meeting/calendar information with
>   RH> Notes, Evolution, and Outlook users.
>
> *shudder*

Yup.  Like it or not though, some people *have* to do things like
that.  Using Gnus would make it a whole lot better.

-- 
Lift me down, so I can make the Earth tremble.
                                --Bucky Katt

Re: Ideas for .no Gnus

[Ted Zlatanov]

On Fri, 02 May 2003, usereplyto@Frank-Schmitt.net wrote:
> *themes*: It would be quite cool if people could export their
>  settings for the various ...-line-format variables (especially
>  gnus-summary-line-format) to a file so they can easily exchange
>  them, Gnus could also include some predefined sets (e.g. classic,
>  slrn-like, table-format...)

Are all those variables called *-format?  Is there a canonical list in
Gnus somewhere?

> *configuration wizard*: This one is AFAIK already quite high in the
>  todo list of Larsi, my idea would be short questions in the
>  minibuffer and an explanation of what the user is supposed to
>  answer in the active buffer, but there are probably other, better
>  ways of implementing it.

I would love to see this.  Configuring the spam.el features is very
hard for a beginner, so I'll definitely contribute to the wizards'
code and testing when their design solidifies.  I think the design and
configuration format were discussed on the ding list not too long ago.

> *images in summary buffer* It would be nice, if it was possible to
>  use small images instead of characters for the different marks in
>  summary buffer.

I like this idea!

> *cache of seen message-ids* Discussed some threads above: Some
>  solution which helps synchronizing .newsrc between two Gnus which
>  read news from different servers would help all those who read
>  e.g. at home from a Leafnode and at work from some other news
>  server.

gnus-registry.el keeps track of all seen message IDs automatically for
you, both by tracking message move/delete/copy/spool actions, and by
registering messages whenever it enters a group.  It does this by
keeping a hashtable for fast access, converted to an alist when it's
saved to the .newsrc.eld as gnus-registry-alist.  Currently only the
group name(s) for the article is kept, but there is room for arbitrary
extra data *associated with the message ID*.  Unfortunately the alist
grows quickly, so maybe I will move gnus-registry-alist to a file
separate from .newsrc.eld.

I just finished the gnus-registry.el basic work, and now I'm about to
start using it for tracking message processing with spam.el.  There's
no problem with hooking into the registry for tracking other message
data, but check with me since I want to keep the API consistent.

Thanks
Ted

A different spam model, which might be possible already (was Re: Ideas for .no Gnus)

[Zack Weinberg]

Frank Schmitt <usereplyto@Frank-Schmitt.net> writes:

> Hello
>
> Now that Oort is released, I'd like to throw some ideas in, which
> features I as (primarily) a user would like to see in the next Gnus:

This is the second of my two wishes:

I use Gnus primarily to get at my mail, which is stored on an IMAP
server.  Mail is sorted into folders by a maildrop script which runs
on the server.  This script is also responsible for running bogofilter
to weed out spam, which is sent to a separate folder; thus the
bogofilter database is stored on that machine, too. I have shell
access to the machine which stores the mail.

I have not yet been able to figure out how to use Gnus' spam features
to feed error corrections back to bogofilter on the remote machine.
The way I would like it to work is:

* If I do 'B m' on message(s) in the spam group, they automagically
  get their $ mark removed.  Also, a hook fires which runs a program
  on the local machine.  This program gets the IMAP UIDs of all the
  moved messages as arguments.  It does *not* get the text of the
  messages on its standard input or elsewhere.  It does not need to
  know the destination of the messages.  The move command is issued to
  the IMAP server only after this program finishes.

* If I mark messages in ham groups as spam ($), then on group exit
  another hook fires which, again, runs a program on the local
  machine, passing the IMAP UIDs of all the spam-marked messages as
  arguments.  This program does need to know the name of the group
  containing the messages - presumably that is an argument too.  After
  the program finishes, all the spam-marked messages are deleted as if
  with 'B DEL', and then EXPUNGE is issued.

The programs run on the local machine are going to ssh over to the
machine which stores the mail, dig the messages out of the mailboxes,
and run bogofilter database update commands on them.  There's no need
to download the messages to the local machine and then send them back
to the server, but there is a need for the messages not to get deleted
or moved until the aforementioned digging happens.

All of this may be possible right now in Oort, but I don't know how to
do it.  There is nothing in the manual about a setup like this, and I
am not familiar enough with Gnus' internals to know where to look for
appropriate hooks, internal functions, etc.  I do know enough Emacs
Lisp that I can probably code this myself given enough pointers.

zw

Re: A different spam model, which might be possible already

[Ted Zlatanov]

On Fri, 02 May 2003, zack@codesourcery.com wrote:
> I use Gnus primarily to get at my mail, which is stored on an IMAP
> server.  Mail is sorted into folders by a maildrop script which runs
> on the server.  This script is also responsible for running
> bogofilter to weed out spam, which is sent to a separate folder;
> thus the bogofilter database is stored on that machine, too. I have
> shell access to the machine which stores the mail.
> 
> I have not yet been able to figure out how to use Gnus' spam
> features to feed error corrections back to bogofilter on the remote
> machine.  The way I would like it to work is:
> 
> * If I do 'B m' on message(s) in the spam group, they automagically
>   get their $ mark removed.  

Currently, the behavior is the reverse: if the articles have a
ham-mark in a spam group (see the ham-marks group parameter) they will
be moved out of the spam group to the ham-process-destination group
after being processed with the group's ham processors.  What you
describe could be coded as alternate behavior, but I don't see the
advantage (see later about article moving and tracking).

> Also, a hook fires which runs a program on the local machine.  This
> program gets the IMAP UIDs of all the moved messages as arguments.
> It does *not* get the text of the messages on its standard input or
> elsewhere.  It does not need to know the destination of the
> messages.  The move command is issued to the IMAP server only after
> this program finishes.

This hook can be a ham processor, invoked once per ham article.  The
processor will get each article number, and could then grab the IMAP
UIDs using the article number.  Then, an arbitrary shell command could
be executed after all the articles have been queued up (so this shell
command would be run after the ham processor has been invoked on each
hap article).  The shell command would login to the remote server and
get the article UIDs as standard input; on the other side you can run
something that can interpret the article UIDs and feed them to
bogofilter.

I'm not sure what's the benefit of doing the article move on the
server side.  Isn't it better to let Gnus do the move, since it will
involve about the same amount of (minimal) network traffic?  Or is the
nnimap remote article move somehow suboptimal?

> * If I mark messages in ham groups as spam ($), then on group exit
>   another hook fires which, again, runs a program on the local
>   machine, passing the IMAP UIDs of all the spam-marked messages as
>   arguments.  This program does need to know the name of the group
>   containing the messages - presumably that is an argument too.
>   After the program finishes, all the spam-marked messages are
>   deleted as if with 'B DEL', and then EXPUNGE is issued.

This works analogously to what's above for ham articles in spam
groups.  If the spam-destination parameter for a ham group is nil, the
spam articles will be only marked as expired.  If it's set to a group
name, the spam articles will be moved to that group and marked as
expired.  Regardless, the spam-processor for the ham group will be
invoked on each article, so it could queue up the IMAP UIDs and you
could pipe them to a single shell command afterwards.

> The programs run on the local machine are going to ssh over to the
> machine which stores the mail, dig the messages out of the
> mailboxes, and run bogofilter database update commands on them.
> There's no need to download the messages to the local machine and
> then send them back to the server, but there is a need for the
> messages not to get deleted or moved until the aforementioned
> digging happens.

Why?  As long as you don't expunge or expire the articles before
calling the shell pipe for ham articles in spam groups or spam
articles in ham groups, spam.el will know if they got moved to another
group or were left in the original group, marked as expired.  It can
tell that to the shell pipe to the remote server.

> All of this may be possible right now in Oort, but I don't know how
> to do it.  There is nothing in the manual about a setup like this,
> and I am not familiar enough with Gnus' internals to know where to
> look for appropriate hooks, internal functions, etc.  I do know
> enough Emacs Lisp that I can probably code this myself given enough
> pointers.

I think I understand what you want, and you definitely need a custom
spam/ham processor that will queue up message UIDs into a file or a
Lisp list.  You may also need a change in behavior, if you don't like
the mark-then-move procedure above and want the move-then-mark
procedure you described.  Finally, you will need a custom function
that will take the queued spam or ham message UIDs and feed them to a
remote shell script; this doesn't have to be a part of spam.el.

It sounds very useful, and I could certainly use something similar now
that my ISP has SpamAssassin on the mail server (but I was too lazy to
write it so far :)

Thanks
Ted

Re: A different spam model, which might be possible already

[Zack Weinberg]

Ted Zlatanov <tzz@lifelogs.com> writes:

>> * If I do 'B m' on message(s) in the spam group, they automagically
>>   get their $ mark removed.  
>
> Currently, the behavior is the reverse: if the articles have a
> ham-mark in a spam group (see the ham-marks group parameter) they will
> be moved out of the spam group to the ham-process-destination group
> after being processed with the group's ham processors.  What you
> describe could be coded as alternate behavior, but I don't see the
> advantage (see later about article moving and tracking).

The trouble with ham-process-destination is there isn't just one ham
group.  Most of the false positives I get with the current static
database belong to various mailing lists.  But I don't use splitting,
so Gnus doesn't have any way of knowing which mailing-list folder a
message belongs to.  Hence, I need to specify it by hand, using 'B m'.  

> I'm not sure what's the benefit of doing the article move on the
> server side.  Isn't it better to let Gnus do the move, since it will
> involve about the same amount of (minimal) network traffic?  Or is the
> nnimap remote article move somehow suboptimal?

I wasn't suggesting not to let Gnus do the move (I'm not sure whether
nnimap remote move is optimal or not, but that's a separate problem).
What I want to avoid is having Gnus read the entire message from the
server and then feed it into an ssh pipe straight back to the server.
Hence the dance with the IMAP UIDs and the remote script needing to
know which group the messages are in at the time it runs.

>> there is a need for the messages not to get deleted or moved until
>> the aforementioned digging happens.
>
> Why?  As long as you don't expunge or expire the articles before
> calling the shell pipe for ham articles in spam groups or spam
> articles in ham groups, spam.el will know if they got moved to another
> group or were left in the original group, marked as expired.  It can
> tell that to the shell pipe to the remote server.

In the proposed scheme I am playing fast and loose with internal
details of Courier IMAP mailboxes in order to map UIDs to messages on
the server side.  I do not want to risk complicating the issue by
having this happen after the server-side state of these messages
changes.

zw

Re: A different spam model, which might be possible already

[Ted Zlatanov]

On Sun, 04 May 2003, zack@codesourcery.com wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:
> 
>>> * If I do 'B m' on message(s) in the spam group, they
>>>   automagically get their $ mark removed.
>>
>> Currently, the behavior is the reverse: if the articles have a
>> ham-mark in a spam group (see the ham-marks group parameter) they
>> will be moved out of the spam group to the ham-process-destination
>> group after being processed with the group's ham processors.  What
>> you describe could be coded as alternate behavior, but I don't see
>> the advantage (see later about article moving and tracking).
> 
> The trouble with ham-process-destination is there isn't just one ham
> group.  Most of the false positives I get with the current static
> database belong to various mailing lists.  But I don't use
> splitting, so Gnus doesn't have any way of knowing which
> mailing-list folder a message belongs to.  Hence, I need to specify
> it by hand, using 'B m'.

We could make ham-process-destination a function in addition to a
plain string, and have the function invoked on each spam message to
return a string.  It can be similar for spam-process-destination and
ham messages.  Would that help, or must you use manual move?

It's unfortunate you don't use splitting, that would make things
easier.

Anyhow, if none of the suggestions work for you, we can certainly
implement the move-then-mark behavior in spam.el.  I don't think it
will be too hard, in fact it can coexist with the mark-then-move
behavior pretty cleanly.

>> I'm not sure what's the benefit of doing the article move on the
>> server side.  Isn't it better to let Gnus do the move, since it
>> will involve about the same amount of (minimal) network traffic?
>> Or is the nnimap remote article move somehow suboptimal?
> 
> I wasn't suggesting not to let Gnus do the move (I'm not sure
> whether nnimap remote move is optimal or not, but that's a separate
> problem).  What I want to avoid is having Gnus read the entire
> message from the server and then feed it into an ssh pipe straight
> back to the server.  Hence the dance with the IMAP UIDs and the
> remote script needing to know which group the messages are in at the
> time it runs.

Hmm.  We could hook into the gnus-summary-article-move-hook and have
it save the UIDs to a file, and then you can run the script that
batch-processes all the UIDs, interactive or hooked on summary exit
for example.

Ted

Re: A different spam model, which might be possible already

[Andrew J. Korty]

Zack Weinberg <zack@codesourcery.com> writes:

> I use Gnus primarily to get at my mail, which is stored on an IMAP
> server.  Mail is sorted into folders by a maildrop script which runs
> on the server.  This script is also responsible for running bogofilter
> to weed out spam, which is sent to a separate folder; thus the
> bogofilter database is stored on that machine, too. I have shell
> access to the machine which stores the mail.
>
> I have not yet been able to figure out how to use Gnus' spam features
> to feed error corrections back to bogofilter on the remote machine.

My configuration is similar, but I just use a bogofilter wrapper
script that shells into the IMAP server.  This approach is different
from the one you proposed, but it works pretty well for me.

All I do is set spam-bogofilter-path to "~/bin/ssh-bogofilter", which
is

    #!/bin/sh
    
    exec /usr/bin/ssh imap.example.com /usr/local/bin/bogofilter "$@"

Hence, the same techniques for marking ham and spam in Gnus on the
IMAP server work everywhere else, too.

It might be more elegant if there were a variable (say,
spam-bogofilter-program) that could be set to something like the
command line above (kind of like imap-shell-program).

-- 
Andrew J. Korty, Principal Security Engineer, GCIA
Office of the Vice President for Information Technology
Indiana University

Re: A different spam model, which might be possible already

[Ted Zlatanov]

On Sat, 03 May 2003, ajk@iu.edu wrote:
> It might be more elegant if there were a variable (say,
> spam-bogofilter-program) that could be set to something like the
> command line above (kind of like imap-shell-program).

How about a "shell" spam-processor?  It seems like a generally useful
thing.

Ted

Re: Ideas for .no Gnus

[Kai Großjohann]

Frank Schmitt <usereplyto@Frank-Schmitt.net> writes:

> *themes*: It would be quite cool if people could export their settings
>  for the various ...-line-format variables (especially
>  gnus-summary-line-format) to a file so they can easily exchange them,
>  Gnus could also include some predefined sets (e.g. classic, slrn-like,
>  table-format...)

Themes will take a long time, but maybe some useful steps could be
taken without themes.  For instance, the custom setting for
gnus-summary-line-format could include some pre-made choices which
users can just choose.

gnus-summary-line-format could also refer to some variables that
people can tune, once they have chosen a read-made choice.  For
instance, the width of the authors column could be such a tunable.

So with less effort, part of the effect can be achieved.

Hm.  Oh, wait, this was actually for the item below.  Argh.  Sorry.

But also it would help if you could tell users to just choose
srln-like from the customization menu for gnus-summary-line-format.

> *configuration wizard*: This one is AFAIK already quite high in the todo
>  list of Larsi, my idea would be short questions in the minibuffer and
>  an explanation of what the user is supposed to answer in the active
>  buffer, but there are probably other, better ways of implementing it.
>
> *A fix for the "Gnus doesn't recognize connection loss problem"* I
>  don't really know why, but for me Gnus fails to recognize it when a
>  server silently drops connection, e.g. because of a timeout. Gnus
>  should really automatically recognize this and restart connection
>  without the need for the user to set some mystique variables (which
>  only exist for nntp and not for e.g. nnimap)

I'm afraid it has to be done in the backends.  But it should be
fairly easy to implement -- there aren't *that* many backends that
speak a network protocol.

> *images in summary buffer* It would be nice, if it was possible to use
>  small images instead of characters for the different marks in summary
>  buffer.

Yes.

> *cache of seen message-ids* Discussed some threads above: Some solution
>  which helps synchronizing .newsrc between two Gnus which read news
>  from different servers would help all those who read e.g. at home from
>  a Leafnode and at work from some other news server.

Whee.  Lars is saying that this is *really* difficult.

> *Support for xpat and xhdr* For those of us who use Gnus for reading
>  news an options to send a xpat search to the news server and create a
>  summary buffer with the matching articles would be nice. Quite some of
>  the required work should already be done in Kai Großjohanns nnir.el.

I'm afraid I haven't looked closely at the copyright situation with
nnir.el, so maybe it can't be included in Gnus.  I also wonder
whether it has the right architecture.  So I wonder if a rewrite
would be in order, that's included in Gnus right away?

> *Leaving messages on pop server* OK, there's epop3.el but it isn't
>  actively maintained as far as I know, so perhaps it would be a good
>  idea to tune Gnus' pop3.el instead.

Yes.  It can't be that difficult, and I actually started on it, but
got nowhere fast.

-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: Ideas for .no Gnus

[Lars Magne Ingebrigtsen]

kai.grossjohann@gmx.net (Kai Großjohann) writes:

>> *cache of seen message-ids* Discussed some threads above: Some solution
>>  which helps synchronizing .newsrc between two Gnus which read news
>>  from different servers would help all those who read e.g. at home from
>>  a Leafnode and at work from some other news server.
>
> Whee.  Lars is saying that this is *really* difficult.

Well, just marking stuff as read by keeping a cache of Message-IDs is
already there.  See `gnus-suppress-duplicates' and friends...

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

Re: Ideas for .no Gnus

[Andreas Fuchs]

On 2003-05-03, Kai Großjohann <kai.grossjohann@gmx.net> wrote:
>> *Support for xpat and xhdr* For those of us who use Gnus for reading
>>  news an options to send a xpat search to the news server and create
>>  a summary buffer with the matching articles would be nice. Quite
>>  some of the required work should already be done in Kai Großjohanns
>>  nnir.el.
> 
> I'm afraid I haven't looked closely at the copyright situation with
> nnir.el, so maybe it can't be included in Gnus.  I also wonder
> whether it has the right architecture.  So I wonder if a rewrite
> would be in order, that's included in Gnus right away?

Oh, err. What you said. I as a user would very much like a workable
searching interface for gnus. I'm probably sufficiently unexposed to
nnir sources to be a possible volunteer for this, but fnord.

-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs
irc.freenode.net's #emacs - online emacs advice from IRC addicts

Re: Ideas for .no Gnus

[Alex Schroeder]

kai.grossjohann@gmx.net (Kai Großjohann) writes:

> Themes will take a long time, but maybe some useful steps could be
> taken without themes.  For instance, the custom setting for
> gnus-summary-line-format could include some pre-made choices which
> users can just choose.

Maybe the time has come to play a bit with custom-theme?  The code is
in both Emacs and XEmacs, so we could start using it...

Alex.
-- 
http://www.emacswiki.org/cgi-bin/alex.pl

Nicer buttons (was: Ideas for .no Gnus)

[Jesper Harder]

Frank Schmitt <usereplyto@Frank-Schmitt.net> writes:

> *Nicer buttons* Some of the Gnus related buttons in the button bar are
>  really nice, but some really don't fit in (e.g. "mark this message as
>  [un]important")

I agree.  

Julien Avarre made some cleaned up and nicer versions of some buttons:

  <http://megarezo.org/perso/eole/gnus/images.html>

(but the server appears to be down right now).

I don't know about copyright assignment stuff -- but apart from that I
think swapping the buttons for cleaned up versions is such a trivial
change that we could even do it in Gnus 5.10.2.

Re: Nicer buttons

[Julien Avarre]

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

Jesper Harder <harder@myrealbox.com> disait récemment  :

> Frank Schmitt <usereplyto@Frank-Schmitt.net> writes:
> 
> > *Nicer buttons*  Some of the Gnus related buttons  in the button bar
> > are really  nice, but  some really don't  fit in (e.g.  "mark this
> > message as [un]important")
> 
> I agree.  
> 
> Julien Avarre made some cleaned up and nicer versions of some buttons:
> 
>   <http://megarezo.org/perso/eole/gnus/images.html>
> 
> (but the server appears to be down right now).

That's sadly true :-(, This is a friend of mine's server under an ADSL
at  home.  Recently  he's  got  some synchronizing  trouble  with  his
provider ...

I've made  a tarball of the  image gallery (1012  ko uncompressed) and
I'm looking for a nice soul for hosting the Gallery somewhere else.

Please just send me an email and I'll send you back the tarball of the
gallery.

> I don't know about copyright assignment stuff 

`` The world is free ´´ ;-)

> But  apart from that  I think  swapping the  buttons for  cleaned up
> versions is such  a trivial change that we could even  do it in Gnus
> 5.10.2.

I'm  totally sharing  your opinion,  Gnus' currents  button  are quite
ugly.

When I posted  my patched buttons, someone said that  they were not in
line of  XEmacs'.  We  shouldn't replace all  of them, but  only some,
particularly colored ones.

-- 
Julien ``Eole'' Avarre
julien at avarre dot com

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Nicer buttons

[luis fernandes]

>>>>> "julien" == Julien Avarre <julien@avarre.com> writes:

    julien> I've made a tarball of the image gallery (1012 ko
    julien> uncompressed) and I'm looking for a nice soul for hosting
    julien> the Gallery somewhere else.

If the general consessus is that some or all of the icons need to be
replaced, then you have my blessings; they can easily be hosted on
gnus.org.

    >> I don't know about copyright assignment stuff

    julien> `` The world is free ´´ ;-)

No it isn't. Before the Gnus with the new icons gets included into
the next Emacs distribution, you will probably have to sign papers
assigning copyright to the FSF. I had to for the logo and the current
*ahem* ugly icons.

Re: Nicer buttons

[Julien Avarre]

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

luis fernandes <elf@ee.ryerson.ca> disait récemment  :

> >>>>> "julien" == Julien Avarre <julien@avarre.com> writes:
> 
>     julien> I've made a tarball of the image gallery (1012 ko
>     julien> uncompressed) and I'm looking for a nice soul for hosting
>     julien> the Gallery somewhere else.
> 
> If the general consessus is that some or all of the icons need to be
> replaced, then you have my blessings; they can easily be hosted on
> gnus.org.

Thanks, Now we need to choose  which images are going to be changed. 

I use GNU Emacs  and I can say that colored buttons  really need to be
changed. But  as I heard,  XEmacs' buttons don't really  need changing
because  of  an  integrity  idea,  kind of  harmony  with  the  others
packages.

We should continue in this idea. Any suggestion ?
 
>     >> I don't know about copyright assignment stuff

So, I guess, me either in fact  ;-)

>     julien> `` The world is free ´´ ;-)
                             ^
                          not so  
Am I right now ? ;-)

> No it isn't. Before the Gnus with the new icons gets included into
> the next Emacs distribution, you will probably have to sign papers
> assigning copyright to the FSF. I had to for the logo and the
> current *ahem* ugly icons.

I understand. I was saying that  because most of colored icons used by
Gnus are from GTK/Gnome, aren't they ? Anyway, there is no trouble for
that, I can  sign if it's needed.  This buttons  are not mine, they're
Gnus' now.

Tcheers, 

-- 
Julien ``Eole'' Avarre
julien at avarre dot com

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Nicer buttons

[Jesper Harder]

luis fernandes <elf@ee.ryerson.ca> writes:

>>>>>> "julien" == Julien Avarre <julien@avarre.com> writes:
>
>     >> I don't know about copyright assignment stuff
>
>     julien> `` The world is free ´´ ;-)
>
> No it isn't. Before the Gnus with the new icons gets included into
> the next Emacs distribution, you will probably have to sign papers
> assigning copyright to the FSF. I had to for the logo and the current
> *ahem* ugly icons.

Yup, but I wasn't sure about where you draw the line for artwork.

If I remember correctly, Julien didn't make any _new_ icons.  He just
cleaned some of the existing icons up, to make the style more
consistent.

(Some of the icon we use are derived from the ones bundled with Emacs,
and some were designed for Gnus -- so the style varies a bit).

Re: Nicer buttons

[luis fernandes]

    harder> If I remember correctly, Julien didn't make any _new_
    harder> icons.  He just cleaned some of the existing icons up, to
    harder> make the style more consistent.

    harder> (Some of the icon we use are derived from the ones
    harder> bundled with Emacs, and some were designed for Gnus -- so
    harder> the style varies a bit).

OK, someone will have to check with rms whether papers are required
for this or not. Using unchanged icons that are bundled with Emacs is
not a problem.

Re: Ideas for .no Gnus

[Lars Magne Ingebrigtsen]

Frank Schmitt <usereplyto@Frank-Schmitt.net> writes:

> *themes*: It would be quite cool if people could export their settings
>  for the various ...-line-format variables (especially
>  gnus-summary-line-format) to a file so they can easily exchange them,
>  Gnus could also include some predefined sets (e.g. classic, slrn-like,
>  table-format...)
>
> *configuration wizard*: This one is AFAIK already quite high in the todo
>  list of Larsi, my idea would be short questions in the minibuffer and
>  an explanation of what the user is supposed to answer in the active
>  buffer, but there are probably other, better ways of implementing it.

Yes.  :-)

But a configuration wizard could also be used to implement themes,
now that I think about it...

> *images in summary buffer* It would be nice, if it was possible to use
>  small images instead of characters for the different marks in summary
>  buffer.

Emacs is still quite slow when displaying images.  Having a buffer
with several thousand images in it is probably going to be unworkable
for most people.

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

Re: Ideas for .no Gnus

[Andreas Fuchs]

On 2003-05-02, Frank Schmitt <usereplyto@frank-schmitt.net> wrote:
> *Support for xpat and xhdr* For those of us who use Gnus for reading
>  news an options to send a xpat search to the news server and create a
>  summary buffer with the matching articles would be nice. Quite some
>  of the required work should already be done in Kai Großjohanns
>  nnir.el.

What I wish for in No Gnus: something very much like nnir (or nnir
itself), with support for more than one backend.


-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs
irc.freenode.net's #emacs - online emacs advice from IRC addicts

Re: Ideas for .no Gnus

[Kai Großjohann]

Andreas Fuchs <asf@void.at> writes:

> On 2003-05-02, Frank Schmitt <usereplyto@frank-schmitt.net> wrote:
>> *Support for xpat and xhdr* For those of us who use Gnus for reading
>>  news an options to send a xpat search to the news server and create a
>>  summary buffer with the matching articles would be nice. Quite some
>>  of the required work should already be done in Kai Großjohanns
>>  nnir.el.
>
> What I wish for in No Gnus: something very much like nnir (or nnir
> itself), with support for more than one backend.

The current nnir.el groks more than one backend, I think.

But still, a rewrite would be nice, I think.
-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)