Forwarding Mail Messages

Forwarding Mail Messages

[Brian May]

Hello All,

There was some concern over my proposal to allow forwarding of
mail while entering a message that it might be difficult to implement.

Here is a way to implement it that I think would be very simple.
However, it requires a different mind set compared with mutt. 

1. The user goes to the group buffer, and marks (#) messages
that he/she wants to forward.

2. The user pushes special keystroke (to be invented), which invokes
a function. This function automatically copies and/or appends entries
to the buffer[1][2], in one of three formats:

A) reference message number

#part type="message/rfc822" group="nnml+private:mail.misc" message=1
#/part

B) reference message id

#part type="message/rfc822" group="nnml+private:mail.misc" message=<19991119091033.A23706@snoopy.apana.org.au>
#/part

C) include message
#part type=message/rfc822 disposition=inline
[...]
#/part

3. The use pushes C-y to insert buffer into message.

4. When the message is sent, it is fetched from the appropriate
group, as appropriate. This is similar to attaching a file.

Which one? A), B), or C)? Personally I prefer one of A) or B). When I
forward a message, I don't particular want to edit it, and these
methods are more convenient. However, C) would require fewer changes.
 
B) might be slowest, but might also be more convenient if typing in
the entry manually.

Note:
[1] I think the is the correct notation ;-)
[2] edited, so I can send it... put < and > at start and end of each entry
-- 
Brian May <bmay@csse.monash.edu.au>

Re: Forwarding Mail Messages

[Lars Magne Ingebrigtsen]

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

> Here is a way to implement it that I think would be very simple.
> However, it requires a different mind set compared with mutt. 
> 
> 1. The user goes to the group buffer, and marks (#) messages
> that he/she wants to forward.
> 
> 2. The user pushes special keystroke (to be invented), which invokes
> a function. This function automatically copies and/or appends entries
> to the buffer[1][2], in one of three formats:

An even more general way to do this would be a way to create an
nnvirtual group based on an arbitrary subset of messages from various
groups.  I don't actually think it would be difficult to implement,
but, er, I don't really see much utility here.  One can, instead, just 
save the messages and then forward the result.

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

Re: Forwarding Mail Messages

[Nevin Kapur]

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

 [...]

 LMI> An even more general way to do this would be a way to create an
 LMI> nnvirtual group based on an arbitrary subset of messages from
 LMI> various groups.  I don't actually think it would be difficult to
 LMI> implement, but, er, I don't really see much utility here.  One
 LMI> can, instead, just save the messages and then forward the
 LMI> result.

This would be super useful. Something similar VM's virtual
folders. The functionality I am looking for is like that  of Gnus'
gnus-summary-limit-to-* but acting on *all* articles in the group(s)
rather than just the ones visible in the summary. Earlier when I used
VM I had the following as part of my virtual folder specifications:

,----
| (setq vm-virtual-folder-alist
|       (list
|        '("unreplied"
|          (("Inbox")
|           (and (unreplied) (not(label "info")))))
|        ))
`----


i.e, create a virtual folder called "unreplied" by taking messages
from "Inbox" which are unreplied and are not labeled "info". VM can
slurp a subset of messages from a particular file or directory. I miss 
this feature.

-Nevin

What now? (was: Forwarding Mail Messages)

[Lars Magne Ingebrigtsen]

Nevin Kapur <nevin@jhu.edu> writes:

> i.e, create a virtual folder called "unreplied" by taking messages
> from "Inbox" which are unreplied and are not labeled "info". VM can
> slurp a subset of messages from a particular file or directory. 

That does sound useful, but requires that Gnus have the ability to
label messages, and it can't, at present.

Client-side labels wouldn't be that difficult to implement, if someone
would want to do that.  Perhaps as a shadow hierarchy of labels and
notes to go with the groups.  (Client-side (i.e. Gnus) as opposed to
server-side (nn*) since that would mean just implementing these things
once.)

Anyway, I was thinking while in the shower -- what now?  Pterodactyl
Gnus was kinda about MIME support and multilingualization.  Along the
way, stuff like the article display revamp, nnimap, mail-fetching,
posting styles, and lotsa web-based interfaces was added.

But is there anything major, like MIME, left to implement.  Is Gnus
(don't say it!) getting feature-complete?

I don't believe that for a second, but I've been asked a couple of
times -- what's next?  And I can't really think of any biggies for the
O-named Gnus series.

Perhaps the next step should be to make Gnus usable^H^H^H^Her-friendly.

Nah.

I'm sure somebody will think of something.  :-)  Or one could start
working on that TODO list that's in the manual.

...

Nah.

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

Re: What now?

[Brian May]

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

    Lars> I'm sure somebody will think of something.  :-) Or one could
    Lars> start working on that TODO list that's in the manual.

If you seriously want suggestions for new features ;-)


I have always felt it would be benefit if I could have a mail program
(eg PGnus) that was integrated with a calander program (eg the one
that comes with xemacs).

That would be used something like the following:

- browsing through the calendar, you see that there are four messages
attached to tomorrow's date. You click on a link, and it automatically
shows a message, where your boss is reminding you about an important
due date that you had forgotten about.

- when this due date is near, PGnus automatically makes the
message as important (!), even if you have already read it.

- after the due date has elapsed, PGnus automatically marks
the message as expirable and/or deletes it immediately.  

- another possibility: You see a message, and think you might be able
to reply to it, but first you want to wait a week, just in case
anybody else (with a better understanding) replies first. You could
mark the message with ?, but then you may forget about it if no one
else replies (which might be a good thing ;-) ). So you could set a
rule "mark this message with ! in one week's time". Or even better:
"mark this message and all followups with ! in one week's time".


As for implementing this stuff, I don't know how you would do it.

It is just something I have always wanted. At the moment, I have
folders set (mbox format, haven't converted to PGnus yet) as

~/Mail/calender/y$year/m$month

but this is awkward and inconvenient, and there is no way to sort by
date. Similarly, there is no way to "attach" multiple dates
to one item of mail, without making duplicates, which is even
messier.
-- 
Brian May <bmay@csse.monash.edu.au>

Re: What now?

[Colin Marquardt]

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

> If you seriously want suggestions for new features ;-)
[...]
> - another possibility: You see a message, and think you might be able
> to reply to it, but first you want to wait a week, just in case
> anybody else (with a better understanding) replies first. You could

Seen remeber.el 1.0 on gnu.emacs.sources today? Not exactly what you
want, but at least for Gnus.

Colin

Re: What now?

[Jody M. Klymak]

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

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
    Lars> I'm sure somebody will think of something.  :-) Or one could
    Lars> start working on that TODO list that's in the manual.

    BM> If you seriously want suggestions for new features ;-)


    BM> I have always felt it would be benefit if I could have a mail
    BM> program (eg PGnus) that was integrated with a calander program
    BM> (eg the one that comes with xemacs).

Hi all, I'd second this.  MS-Outlook is generally pretty bad, but it
has some nice PIM-oriented features.  For instance, you can drag an article into
the calendar and associate the article with a certain date.  Saves
retyping everything into diary.  

I was also thinking that perhaps a hyper diary may be a nice thing.
The diary would accept hyperlinks (much the way that gnus does now, or
Asvin Goel's Records Mode
http://www.cse.ogi.edu/~ashvin/software.html).  Then you could write a
lisp function to save your article to a text file (or mbox) and add a
hyperlink to your diary.  Hmmmm.  Perhaps beyond the purview of gnus,
but it'd sure be slick.  gnus already has a nice interface to BBDB,
perhaps it can be easily extended to Calendar and diary.

Cheers,  Jody

-- 
Jody Klymak                         APL/School of Oceanography,
Doctoral Candidate                  University of Washington
mailto:jklymak@apl.washington.edu   (206)-685-9080
http://www.ocean.washington.edu/people/grads/jklymak/

Re: What now?

[Lars Magne Ingebrigtsen]

"Jody M. Klymak" <jklymak@apl.washington.edu> writes:

> I was also thinking that perhaps a hyper diary may be a nice thing.
> The diary would accept hyperlinks (much the way that gnus does now, or
> Asvin Goel's Records Mode
> http://www.cse.ogi.edu/~ashvin/software.html).  Then you could write a
> lisp function to save your article to a text file (or mbox) and add a
> hyperlink to your diary. 

That sounds kinda neat.  If Gnus had a proper "refer article from
outside of Gnus" function, Gnus could handle the "news:" URLs.

Gnus startup is slow and does lots of stuff, so such a function should 
just start up a minimal part of Gnus (unless it's already running),
and not create the group or summary buffers, but just the article
buffer and display the article there.  All normal Gnus commands for
doing stuff with articles should be valid there.

This is easier typed than done, though.  All the article mode commands 
rely on the summary existing, and there are lots of commands that
wouldn't be valid (like, `B c' -- you can't copy to another group if
Gnus isn't "really" running, I'd think).

Hm.  Anobody got any suggestions as to how this could be achieved in a 
fashion that would not require Lots Of Work(tm)?

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

Re: What now?

[Brian May]

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

    Lars> "Jody M. Klymak" <jklymak@apl.washington.edu> writes:
    >> I was also thinking that perhaps a hyper diary may be a nice
    >> thing.  The diary would accept hyperlinks (much the way that
    >> gnus does now, or Asvin Goel's Records Mode
    >> http://www.cse.ogi.edu/~ashvin/software.html).  Then you could
    >> write a lisp function to save your article to a text file (or
    >> mbox) and add a hyperlink to your diary.

    Lars> That sounds kinda neat.  If Gnus had a proper "refer article
    Lars> from outside of Gnus" function, Gnus could handle the
    Lars> "news:" URLs.

I think this would be really good. 

Another feature (one that doesn't look like its already implemented at
least) could be a "write new message with these headers" function,
that could be called, eg by w3. Currently, while w3 uses Gnus message
mode, major Gnus features, eg MIME and gnus-posting styles don't
appear to be supported. However, this would require co-operation
from w3.

    Lars> Gnus startup is slow and does lots of stuff, so such a
    Lars> function should just start up a minimal part of Gnus (unless
    Lars> it's already running), and not create the group or summary
    Lars> buffers, but just the article buffer and display the article
    Lars> there.  All normal Gnus commands for doing stuff with
    Lars> articles should be valid there.

Personally, I think Gnus is the type of mailer I try to keep running
all the time. Especially because it is slow to start up. Even if such
a function returned an error "Gnus not running", I think that would be
acceptable - especially if a lot of work is required to change things.

    Lars> This is easier typed than done, though.  All the article
    Lars> mode commands rely on the summary existing, and there are
    Lars> lots of commands that wouldn't be valid (like, `B c' -- you
    Lars> can't copy to another group if Gnus isn't "really" running,
    Lars> I'd think).

Perhaps, one day you may have to remove a lot of these assumptions
anyway. Why do article mode commands rely on the summary?

I tend to think it might be a benefit, in some circumstances,
to have an article window open, without the summary window. Not
that I feel to strongly about it.

    Lars> Hm.  Anobody got any suggestions as to how this could be
    Lars> achieved in a fashion that would not require Lots Of
    Lars> Work(tm)?

Do everything twice. Then it will no longer be "lots of work".
Instead, it will be "more then lots of work" ;-)

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

Re: What now?

[William M. Perry]

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

> >>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
>     Lars> "Jody M. Klymak" <jklymak@apl.washington.edu> writes:
>     >> I was also thinking that perhaps a hyper diary may be a nice
>     >> thing.  The diary would accept hyperlinks (much the way that
>     >> gnus does now, or Asvin Goel's Records Mode
>     >> http://www.cse.ogi.edu/~ashvin/software.html).  Then you could
>     >> write a lisp function to save your article to a text file (or
>     >> mbox) and add a hyperlink to your diary.
> 
>     Lars> That sounds kinda neat.  If Gnus had a proper "refer article
>     Lars> from outside of Gnus" function, Gnus could handle the
>     Lars> "news:" URLs.

Well, Emacs/W3 already uses gnus for that, so that should be pretty simple
to do. :)

> I think this would be really good. 
> 
> Another feature (one that doesn't look like its already implemented at
> least) could be a "write new message with these headers" function, that
> could be called, eg by w3. Currently, while w3 uses Gnus message mode,
> major Gnus features, eg MIME and gnus-posting styles don't appear to be
> supported. However, this would require co-operation from w3.

Easily accomplished. :) The problem with using gnus posting styles for
Emacs/W3 mailto: URLs is that not everybody clicks those links from within
Gnus.  Emacs/W3 uses _message_, not Gnus for sending the mail.  There might
be a case for having w3 allow customization of posting styles based on
email address or the URL the link is on, something like that.

-bp

Re: What now?

[Brian May]

>>>>> "William" == William M Perry <wmperry@aventail.com> writes:

    William> Well, Emacs/W3 already uses gnus for that, so that should
    William> be pretty simple to do. :)

When I tried it, W3 seemed to use its on interface for the job, and
didn't use Gnus. For instance, w3 requires the NNTP server to be
configured separately from Gnus.

I seem to remember another difference: when clicking on a news link
from Gnus, Gnus will look up all back ends for the message, but
when clicking on it from w3, w3 will only check with the nntp
server.

I think solving these issues would help significantly with my
initial "wish list", article
news:t4in1ruvyij.fsf_-_@silas-2.cc.monash.edu.au

If you don't understand how this could help, please tell me, and
I will give some examples.

(side note: I have seen a number of embedded URLs in news documents of
the form "news:messageid...". Note the trailing periods. This breaks
Gnus, as it doesn't remove them before trying to fetch the article :-(
eg that previous article would be written as:
news:t4in1ruvyij.fsf_-_@silas-2.cc.monash.edu.au...
)

    William> Easily accomplished. :) The problem with using gnus
    William> posting styles for Emacs/W3 mailto: URLs is that not
    William> everybody clicks those links from within Gnus.  Emacs/W3

Thats what I meant. I want to be able to click on the link from
w3. Same goes for the issue above. I think it should work for links
you click on outside of Gnus, using Gnus, so that I don't have to
duplicate my configuration for w3.

Come to think if it though, I have never yet seen a message
with a mailto url...

    William> uses _message_, not Gnus for sending the mail.  There
    William> might be a case for having w3 allow customization of
    William> posting styles based on email address or the URL the link
    William> is on, something like that.

No - I would much prefer a Gnus function that w3 can call "send mail
with these headers". That way, there is no need to re-invent the rule
and redo what has already been implemented.

Of course, it gets a bit messier when you deal with multiple groups,
and possibly this needs to be discussed a bit more. I would be happy
if everything just matched a preset group, eg "w3". Another
alternative, is that w3 could somehow track which group you originally
loaded the web page from (if any). I suspect this might be difficult
to implement and use though.

As I have already said earlier, I don't think it matters if there
is the requirement "Gnus must be running beforehand".
-- 
Brian May <bmay@csse.monash.edu.au>

Re: What now?

[William M. Perry]

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

> >>>>> "William" == William M Perry <wmperry@aventail.com> writes:
> 
>     William> Well, Emacs/W3 already uses gnus for that, so that should
>     William> be pretty simple to do. :)
> 
> When I tried it, W3 seemed to use its on interface for the job, and
> didn't use Gnus. For instance, w3 requires the NNTP server to be
> configured separately from Gnus.

This is changed with the new version of URL - I am in the midst of
rewriting url-news.el right now.

> I seem to remember another difference: when clicking on a news link from
> Gnus, Gnus will look up all back ends for the message, but when clicking
> on it from w3, w3 will only check with the nntp server.

Well, news and nntp URLs are theoretically just for NNTP access.  Gnus is
not exactly envisioned by the guys who wrote the URL for news. :)  I
couldn't find any sort of 'get this messageid regardless of backend'.  If
there is one, could someone send it to me?

> (side note: I have seen a number of embedded URLs in news documents of
> the form "news:messageid...". Note the trailing periods. This breaks
> Gnus, as it doesn't remove them before trying to fetch the article :-( eg
> that previous article would be written as:
> news:t4in1ruvyij.fsf_-_@silas-2.cc.monash.edu.au...  )

THen they have been embedded in the document wrong.  This is what the
<URL:news:t4in1ruvyij.fsf_-_@silas-2.cc.monash.edu.au>... syntax is for. :)

-bp

nnimap URLs? (Was: What now?)

[Steinar Bang]

>>>>> wmperry@aventail.com (William M. Perry):

> This is changed with the new version of URL - I am in the midst of
> rewriting url-news.el right now.

Will you do IMAP URLs as well?
	http://www.faqs.org/rfcs/rfc2192.html

They could be a good start towards an infrastructure for doing delayed
loading of attachments in nnimap mail groups.  nnimap could replace
the attachment MIME parts with an URL external body message part
	http://www.landfield.com/rfcs/rfc2017.html
and when opening the part, the contents of the URL would be fetched
and inserted inline (that is, if Simon hasn't already fixed this in a
different way and I haven't been paying attention...:-) ).

Re: nnimap URLs? (Was: What now?)

[William M. Perry]

Steinar Bang <sb@metis.no> writes:

> >>>>> wmperry@aventail.com (William M. Perry):
> 
> > This is changed with the new version of URL - I am in the midst of
> > rewriting url-news.el right now.
> 
> Will you do IMAP URLs as well?
> 	http://www.faqs.org/rfcs/rfc2192.html

I'm not sure if I know enough about the guts of 'imap.el' to hack this
together or not.  Fortunately, it is easy to add a new URL type. :)  If
anyone (simon?) wants to work on this, let me know and I'll concentrate on
getting the documentation on how to do this written tonight.  I would LOVE
to see this get written.

It should probably be distributed as part of or along with imap.el - is
this only distributed with gnus now?

> They could be a good start towards an infrastructure for doing delayed
> loading of attachments in nnimap mail groups.  nnimap could replace
> the attachment MIME parts with an URL external body message part
> 	http://www.landfield.com/rfcs/rfc2017.html
> and when opening the part, the contents of the URL would be fetched
> and inserted inline (that is, if Simon hasn't already fixed this in a
> different way and I haven't been paying attention...:-) ).

This would kick serious %!@#%!@, I might even gripe about the ridiculously
low quotas on our imap server so I could actually use it.  (Pffft, who
needs only 135 megabytes for storing email :)

-Bill P.

Re: nnimap URLs? (Was: What now?)

[Simon Josefsson]

William M. Perry <wmperry@aventail.com> writes:

> I'm not sure if I know enough about the guts of 'imap.el' to hack this
> together or not.  Fortunately, it is easy to add a new URL type. :)  If
> anyone (simon?) wants to work on this, let me know and I'll concentrate on
> getting the documentation on how to do this written tonight.  I would LOVE
> to see this get written.

If there is a url-nntp.el to look at I could have a go at it.

Re: nnimap URLs? (Was: What now?)

[William M. Perry]

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

Simon Josefsson <jas@pdc.kth.se> writes:

> William M. Perry <wmperry@aventail.com> writes:
> 
> > I'm not sure if I know enough about the guts of 'imap.el' to hack this
> > together or not.  Fortunately, it is easy to add a new URL type. :)  If
> > anyone (simon?) wants to work on this, let me know and I'll concentrate on
> > getting the documentation on how to do this written tonight.  I would LOVE
> > to see this get written.
> 
> If there is a url-nntp.el to look at I could have a go at it.

This is a work-in-progress, but should be a good starting point.  Will this
be able to be asynchronous?  I noticed there was an imap-fetch-asynch call,
but I didn't see how it ever got a callback or anything like that handed to
it.  If it is, you need to add:

(defconst url-imap-asynchronous-p t "IMAP retrievals are asynchronous.")

And the url-imap routine would get a callback and a cbargs argument that it
is expected to call with the current buffer set to where the article is.
If there is no data to return, it just never calls the callback.

If nil is returned (or the callback is not activated), then that means
there is no real data to return (ie: someone did imap://mail.server.com/
and we just go straight into gnus) to the calling app.

Basically, the new URL stuff expects a buffer to look like a MIME message,
with headers intact at the top, including a content-type and content-length
when available.

Any questions, lemme know.

-Bill P.


[-- Attachment #2: url-news.el --]
[-- Type: application/emacs-lisp, Size: 5031 bytes --]

[-- Attachment #3: url-imap.el --]
[-- Type: application/emacs-lisp, Size: 1499 bytes --]

Re: nnimap URLs? (Was: What now?)

[Simon Josefsson]

Steinar Bang <sb@metis.no> writes:

> They could be a good start towards an infrastructure for doing delayed
> loading of attachments in nnimap mail groups.  nnimap could replace
> the attachment MIME parts with an URL external body message part
> 	http://www.landfield.com/rfcs/rfc2017.html
> and when opening the part, the contents of the URL would be fetched
> and inserted inline (that is, if Simon hasn't already fixed this in a
> different way and I haven't been paying attention...:-) ).

I haven't, but I'm sort-of against the idea of modifying an article in
the backend. You'd never really now what the article actually looked
like in the long run...

Unless someone want to implement automatic external-body access-type
stuff in nnimap, I think we should have a go at a MIME-aware backend
interface instead. Here's quick idea:

Introduce a new backend function 'nnfoo-request-body' that return a
MIME structure of the article (the "BODY structure" in IMAP is quite
lisp-ish and would be general enough to work in Gnus).

Also introduce a new backend function `nnfoo-request-body-parts' which
take a list of MIME parts and return the corresponding body part.

The standard article stuff groks theese new functions and use them if
available, and only request the body parts that normally are
displayed.

OTOH external-body access-type would be quite simple, given that there
is a url-imap package.

Re: nnimap URLs? (Was: What now?)

[William M. Perry]

Simon Josefsson <jas@pdc.kth.se> writes:

> Steinar Bang <sb@metis.no> writes:
> 
> > They could be a good start towards an infrastructure for doing delayed
> > loading of attachments in nnimap mail groups.  nnimap could replace
> > the attachment MIME parts with an URL external body message part
> > 	http://www.landfield.com/rfcs/rfc2017.html
> > and when opening the part, the contents of the URL would be fetched
> > and inserted inline (that is, if Simon hasn't already fixed this in a
> > different way and I haven't been paying attention...:-) ).
> 
> I haven't, but I'm sort-of against the idea of modifying an article in
> the backend. You'd never really now what the article actually looked
> like in the long run...

`C-u g' should of course get the entire message.  I think this would be
sufficient.

> Unless someone want to implement automatic external-body access-type
> stuff in nnimap.

They would just have to implement it in the mm-* routines I would think.
Then any message could have external body parts, and nnimap would just take
advantage of it.

-Bill P.

Re: What now?

[Brian May]

>>>>> "William" == William M Perry <wmperry@aventail.com> writes:

    William> Well, Emacs/W3 already uses gnus for that, so that should
    William> be pretty simple to do. :)
    >> When I tried it, W3 seemed to use its on interface for the job,
    >> and didn't use Gnus. For instance, w3 requires the NNTP server
    >> to be configured separately from Gnus.

    William> This is changed with the new version of URL - I am in the
    William> midst of rewriting url-news.el right now.

Ok... Thats Good.

    >> I seem to remember another difference: when clicking on a news
    >> link from Gnus, Gnus will look up all back ends for the
    >> message, but when clicking on it from w3, w3 will only check
    >> with the nntp server.

    William> Well, news and nntp URLs are theoretically just for NNTP
    William> access.  Gnus is not exactly envisioned by the guys who
    William> wrote the URL for news. :) I couldn't find any sort of
    William> 'get this messageid regardless of backend'.  If there is
    William> one, could someone send it to me?

Both M-^ and news URLS from Gnus seem to be able to fetch articles,
regardless of source...

Hang on, no, it depends on the current group selected. If I am in a
NNTP group, I cannot find a mail message (at least for M-^, I haven't
tested news URLS). I would imagine it might be possible to query each
back end in turn???  Perhaps allow the user to select order of
priority?

    William> THen they have been embedded in the document wrong.  This
    William> is what the
    William> <URL:news:t4in1ruvyij.fsf_-_@silas-2.cc.monash.edu.au>... syntax
    William> is for. :)

Thats what I thought too. Does Gnus provide any macros to automate
creating these?
-- 
Brian May <bmay@csse.monash.edu.au>

Re: What now?

[Jody M. Klymak]

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

    LMI> "Jody M. Klymak" <jklymak@apl.washington.edu> writes:
    >> I was also thinking that perhaps a hyper diary may be a nice
    >> thing.  The diary would accept hyperlinks (much the way that
    >> gnus does now, or Asvin Goel's Records Mode
    >> http://www.cse.ogi.edu/~ashvin/software.html).  Then you could
    >> write a lisp function to save your article to a text file (or
    >> mbox) and add a hyperlink to your diary.

    LMI> That sounds kinda neat.  If Gnus had a proper "refer article
    LMI> from outside of Gnus" function, Gnus could handle the "news:"
    LMI> URLs.

    LMI> Gnus startup is slow and does lots of stuff, so such a
    LMI> function should just start up a minimal part of Gnus (unless
    LMI> it's already running), and not create the group or summary
    LMI> buffers, but just the article buffer and display the article
    LMI> there.  All normal Gnus commands for doing stuff with
    LMI> articles should be valid there.

Hi Lars,

Well, no other PIM will do this sort of thing without the mail-reader
running.  I don't think its onerous to expect gnus to be running at
the same time. 

Cheers,  Jody

PS, I *think* I've figured out how to merge vcard attachements with
BBDB.  Its not very robust yet, but thats just due to my inability to
understand LISP.  How *do* you guys do it?  Is there a good emacs Lisp
book around somewhere?  "Writing GNU Emacs Extensions" is a little too
terse for me. 

-- 
Jody Klymak                         APL/School of Oceanography,
Doctoral Candidate                  University of Washington
mailto:jklymak@apl.washington.edu   (206)-685-9080
http://www.ocean.washington.edu/people/grads/jklymak/

Re: What now?

[Bruce Stephens]

"Jody M. Klymak" <jklymak@apl.washington.edu> writes:

[...]

> PS, I *think* I've figured out how to merge vcard attachements with
> BBDB.  Its not very robust yet, but thats just due to my inability
> to understand LISP.  How *do* you guys do it?  Is there a good emacs
> Lisp book around somewhere?  "Writing GNU Emacs Extensions" is a
> little too terse for me.

The Emacs Lisp Reference Manual.  Included in XEmacs, I think.  Also
makes a lovely gift, or doorstop.

Re: What now?

[Kai Großjohann]

"Jody M. Klymak" <jklymak@apl.washington.edu> writes:

> PS, I *think* I've figured out how to merge vcard attachements with
> BBDB.  Its not very robust yet, but thats just due to my inability to
> understand LISP.  How *do* you guys do it?  Is there a good emacs Lisp
> book around somewhere?  "Writing GNU Emacs Extensions" is a little too
> terse for me. 

There is the Emacs Lisp Introduction which I hear is a nice book.
Available as elisp-intro or emacs-lisp-intro from ftp.gnu.org and its
mirrors. 

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

Re: What now? (was: Forwarding Mail Messages)

[Jody M. Klymak]

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

    LMI> But is there anything major, like MIME, left to implement.
    LMI> Is Gnus (don't say it!) getting feature-complete?

Hi all,

Just to reiterate my comments of the other day.  I did some poking
around and realized that there are calendar standards and vcard
standards out there.  

Gnus already has pretty nice integration with BBDB, but it doesn't
parse vcard information.  Now before anyone says that vcards are
silly, you should look at their specification
(http://www.imc.org/pdi/) - I don't think its necessarily a bad idea
to encode all the information that I give in my sig below so that it
can be automatically sucked into someones BBDB if they are so
inclined.  

There is also an accepted Vcalendar standard (again at
http://www.imc.org/pdi/) that allows people to
send meeting information in a standard form.  It might be very nice
to do this - not only would a lot of gnus-users stuck in corporate
environments be able to ditch Outlook, but it may also help propogate
these useful ways of marking up our emails.  The trend is towards more
information content in messages - if there are a few standard
templates we can parse like vcard and vcalendar then so much the
better.

Why do all this in gnus, a news and mail program?  Becuase now adays,
the majority of meetings get scheduled by email, and the majority of
contacts get made that way as well.  It makes sense to integrate the
Personl Information Manager and the mail reader as much as possible -
ythe email client is the glue that holds everything together.  Gnus
can do it - it understands attachements.  There is already a vcard
parser (but no way to dump it into BBDB yet), and I'm sure its not too
difficult to write a vcalendar parser.  So no, I'd not say gnus is
"feature-complete" yet.  There are lots of wonderful things going on
out there that aren't being tapped into yet.

Anyways, just some thoughts.  I may start poking into these things,
but I'm writing my dissertation so I don't have a lot of time.  I'm
also not very lisp-litterate.  

Cheers,  Jody

-- 
Jody Klymak                         APL/School of Oceanography,
Doctoral Candidate                  University of Washington
mailto:jklymak@apl.washington.edu   (206)-685-9080
http://www.ocean.washington.edu/people/grads/jklymak/

Re: What now? (was: Forwarding Mail Messages)

[Hrvoje Niksic]

"Jody M. Klymak" <jklymak@apl.washington.edu> writes:

> Gnus already has pretty nice integration with BBDB, but it doesn't
> parse vcard information.

Gnus does parse vcards, and displays them nicely.  I don't know about
BBDB integration; that part will probably have to be done by the BBDB
people.

Re: What now? (was: Forwarding Mail Messages)

[Jody M. Klymak]

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic@iskon.hr> writes:

    Hrvoje> "Jody M. Klymak" <jklymak@apl.washington.edu> writes:
    >> Gnus already has pretty nice integration with BBDB, but it
    >> doesn't parse vcard information.

    Hrvoje> Gnus does parse vcards, and displays them nicely.  I don't
    Hrvoje> know about BBDB integration; that part will probably have
    Hrvoje> to be done by the BBDB people.

Ooops, sorry that wasn't clear.  It parses vcards but it doesn't pass
the information to BBDB.  

*Are* there BBDB people?  BBDB doesn't seem to get released very
often.

Cheers,  Jody

-- 
Jody Klymak                         APL/School of Oceanography,
Doctoral Candidate                  University of Washington
mailto:jklymak@apl.washington.edu   (206)-685-9080
http://www.ocean.washington.edu/people/grads/jklymak/

Re: What now? (was: Forwarding Mail Messages)

[Lars Magne Ingebrigtsen]

"Jody M. Klymak" <jklymak@apl.washington.edu> writes:

> There is also an accepted Vcalendar standard (again at
> http://www.imc.org/pdi/) that allows people to
> send meeting information in a standard form.  It might be very nice
> to do this - not only would a lot of gnus-users stuck in corporate
> environments be able to ditch Outlook, but it may also help propogate
> these useful ways of marking up our emails.  

So people send these Vcalendar attachments to each other, and Gnus
could have a command for sucking the attachments into the user's
personal calendar?  That kinda sounds actually useful.

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

Re: What now? (was: Forwarding Mail Messages)

[William M. Perry]

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

> "Jody M. Klymak" <jklymak@apl.washington.edu> writes:
> 
> > There is also an accepted Vcalendar standard (again at
> > http://www.imc.org/pdi/) that allows people to
> > send meeting information in a standard form.  It might be very nice
> > to do this - not only would a lot of gnus-users stuck in corporate
> > environments be able to ditch Outlook, but it may also help propogate
> > these useful ways of marking up our emails.  
> 
> So people send these Vcalendar attachments to each other, and Gnus could
> have a command for sucking the attachments into the user's personal
> calendar?  That kinda sounds actually useful.

Well, does anyone actually USE this standard?  I'm pretty sure outlook does
_not_.  The only thing I've seen that uses it is the gnome calendar app.

-bp

Re: What now? (was: Forwarding Mail Messages)

[Arcady Genkin]

wmperry@aventail.com (William M. Perry) writes:

> Well, does anyone actually USE this standard?  I'm pretty sure outlook does
> _not_.  The only thing I've seen that uses it is the gnome calendar app.

According to http://www.imc.org/pdi/pdiprodslist.html, it can actually
import and export in that format. And so do a bunch of other wares.
-- 
Arcady Genkin                                 http://www.thpoon.com
Nostalgia isn't what it used to be.

Re: What now? (was: Forwarding Mail Messages)

[William M. Perry]

Arcady Genkin <a.genkin@utoronto.ca> writes:

> wmperry@aventail.com (William M. Perry) writes:
> 
> > Well, does anyone actually USE this standard?  I'm pretty sure outlook does
> > _not_.  The only thing I've seen that uses it is the gnome calendar app.
> 
> According to http://www.imc.org/pdi/pdiprodslist.html, it can actually
> import and export in that format. And so do a bunch of other wares.

Well, importing and exporting are one thing, but every single meeting
request originating from outlook is in their own format, not vcalendar.  To
me, that spells a good 'migration path' to Gnus, not an interoperability
opportunity.  :(

-bp

Re: What now? (was: Forwarding Mail Messages)

[Hans de Graaff]

wmperry@aventail.com (William M. Perry) writes:

> > So people send these Vcalendar attachments to each other, and Gnus could
> > have a command for sucking the attachments into the user's personal
> > calendar?  That kinda sounds actually useful.
> 
> Well, does anyone actually USE this standard?  I'm pretty sure outlook does
> _not_.  The only thing I've seen that uses it is the gnome calendar app.

Outlook does support it in some sense. You can save a meeting in
vCalendar format and then mail it around.

Hans

Re: What now? (was: Forwarding Mail Messages)

[Kai Großjohann]

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

> But is there anything major, like MIME, left to implement.  Is Gnus
> (don't say it!) getting feature-complete?

One idea which might get pretty big is to move away from the group
concept a bit.  Instead, you specify a `query' and Gnus displays all
the messages matching that `query'.  This would be a generalization of
the label thing, as it would be possible to include conditions on
labels in the query.  (Of course, for all of this we need a way to
attach labels to messages, first.)

This might get messy, but it would also be nifty.  `Show me all the
replies I sent to Paul.'  `What messages were there last month about
the foo project.'  And so on.

I think integrating this with the conventional groups concept in a
clean way would be a major challenge -- might not even be doable at
all.

Something along the above lines has been suggested before.  (Sorry
that I forgot your name!)

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

Re: What now? (was: Forwarding Mail Messages)

[Kai Großjohann]

One other idea would be a bit of CSCW support in Gnus.  I'm not sure
whether this is major, and I'm not even sure if it should be dealt
with within Gnus, but WIBNI one could share a group with others, and
WIBNI it was possible to mark a message as important for the group as
opposed to marking it as important for oneself, and stuff?

And then, there's polls (votes?)...

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

Re: What now? (was: Forwarding Mail Messages)

[Richard Hoskins]

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

[...]

> -- what's next?  And I can't really think of any biggies for the
> O-named Gnus series.

Common Lisp, with a Emacs UI?
:)
-- 
party naked

Re: Forwarding Mail Messages

[Brian May]

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

    Lars> An even more general way to do this would be a way to create
    Lars> an nnvirtual group based on an arbitrary subset of messages
    Lars> from various groups.  I don't actually think it would be
    Lars> difficult to implement, but, er, I don't really see much
    Lars> utility here.  One can, instead, just save the messages and
    Lars> then forward the result.

Can you do so with each message as a separate message/rfc822 attachment?
-- 
Brian May <bmay@csse.monash.edu.au>

Re: Forwarding Mail Messages

[Lars Magne Ingebrigtsen]

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

>     Lars> An even more general way to do this would be a way to create
>     Lars> an nnvirtual group based on an arbitrary subset of messages
>     Lars> from various groups.  I don't actually think it would be
>     Lars> difficult to implement, but, er, I don't really see much
>     Lars> utility here.  One can, instead, just save the messages and
>     Lars> then forward the result.
> 
> Can you do so with each message as a separate message/rfc822 attachment?

None of the article saving function save as multipart/alternative.

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