Suggested features

Suggested features

[Mr Brian May]

>>>>> "Colin" == Colin Marquardt <colin.marquardt@gmx.de> writes:

Suggested features improvements for PGNUs (or perhaps these features
already exist but poorly(?) documented).

    >> - PGP signed MIME attachments (as mentioned on gnu.emacs.gnus).

    Colin> That would be the task of an external package,
    Colin> e.g. mailcrypt.

I will assume that supporting this in mailcrypt doesn't require any changes
to PGnus?

I have never tested mailcrypt yet (just saying what I have heard elsewhere),
so I had better test it before I end up stabbing myself in the foot... ;-)

    >> - ability to forward multiple messages as *seperate* rfc822
    >> mime attachments.

I like to do this in mutt, and a bit surprised Pgnus doesn't do it by
default...

    >> - even better - ability to attach attach a message while you
    >> are already composing a new outgoing message (I have done this
    >>> from mutt, for instance, when replying to one person and
    >>> quoting
    >> abother persons mail).

    Colin> You can always switch to another buffer and browse the
    Colin> groups as you like, copy the message and then return to the
    Colin> buffer "*reply to...*" or "*wide reply to...*" etc. But
    Colin> then, MIME of course. Hmmm.

I suspect that it would be easy to manually add the MIME tags
when pasting the copied message... (not tested - I might be confused -
I think the general idea is sane though).

However, I would much prefer to have that automated to some degree - eg
push keystroke that corresponds to 'attach message', which will allow
you to browse and select a message that you want to attach. Maybe this
is easier said then done.

Anyway, this is a list of the three features I commonly use in Mutt,
and would love to see them in PGnus...
-- 
Brian May <bmay@csse.monash.edu.au>

Re: Suggested features

[Lars Magne Ingebrigtsen]

Mr Brian May <bam@silas.cc.monash.edu.au> writes:

> I will assume that supporting this in mailcrypt doesn't require any changes
> to PGnus?

Yes, I think so.

>     >> - ability to forward multiple messages as *seperate* rfc822
>     >> mime attachments.
> 
> I like to do this in mutt, and a bit surprised Pgnus doesn't do it by
> default...

Do you mean a multipart/mixed message with several message/rfc822
parts? 

> However, I would much prefer to have that automated to some degree - eg
> push keystroke that corresponds to 'attach message', which will allow
> you to browse and select a message that you want to attach. Maybe this
> is easier said then done.

I can't imagine how to do this.

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

Re: Suggested features

[Brian May]

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

    >> >> - ability to forward multiple messages as *seperate* rfc822
    >> >> mime attachments.
    >> 
    >> I like to do this in mutt, and a bit surprised Pgnus doesn't do
    >> it by default...

    Lars> Do you mean a multipart/mixed message with several
    Lars> message/rfc822 parts?

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

Re: Suggested features

[Kai Großjohann]

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

> Mr Brian May <bam@silas.cc.monash.edu.au> writes:
> 
> > However, I would much prefer to have that automated to some degree - eg
> > push keystroke that corresponds to 'attach message', which will allow
> > you to browse and select a message that you want to attach. Maybe this
> > is easier said then done.
> 
> I can't imagine how to do this.

Allow the user to enter any group and select any article.  Upon the
user pressing some key, insert the *Article* buffer into the message
being composed.

Hm.

Is there already a command for attaching a buffer?  Maybe that would
be sufficient.

kai
-- 
This gubblick contains many nonsklarkish English flutzpahs,
but the overall pluggandisp can be glorked from context. -- David Moser

Re: Suggested features

[Hrvoje Niksic]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> > > However, I would much prefer to have that automated to some
> > > degree - eg push keystroke that corresponds to 'attach message',
> > > which will allow you to browse and select a message that you
> > > want to attach. Maybe this is easier said then done.
> > 
> > I can't imagine how to do this.
> 
> Allow the user to enter any group and select any article.  Upon the
> user pressing some key, insert the *Article* buffer into the message
> being composed.

Even better, the command should follow the process/prefix convention,
so that you can attach several articles of your choice, *after* you
start composing a message.  I've always missed this feature.

> Is there already a command for attaching a buffer?  Maybe that would
> be sufficient.

Attaching an *Article* buffer is a bad idea because it's already
washed.  Original article text (which is stored in a separate buffer)
is what you'd have to attach.

Re: Suggested features

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@iskon.hr> writes:

> Even better, the command should follow the process/prefix convention,
> so that you can attach several articles of your choice, *after* you
> start composing a message.  I've always missed this feature.

Even from other groups and stuff, like Kai said?  That would be very
complicated.

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

Re: Suggested features

[Lars Magne Ingebrigtsen]

Brian May <bam@silas-1.cc.monash.edu.au> writes:

>     Lars> Do you mean a multipart/mixed message with several
>     Lars> message/rfc822 parts?
> 
> Yes.

I've added this to the todo list.

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

Re: Suggested features

[Hrvoje Niksic]

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

> Hrvoje Niksic <hniksic@iskon.hr> writes:
> 
> > Even better, the command should follow the process/prefix convention,
> > so that you can attach several articles of your choice, *after* you
> > start composing a message.  I've always missed this feature.
> 
> Even from other groups and stuff, like Kai said?

It would be nice.  Provided the Group buffer in question remains
alive.

> That would be very complicated.

Even a simplification would be nice, only to get the feature in _some_
form.

Re: Suggested features

[Kai Großjohann]

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

> Even from other groups and stuff, like Kai said?  That would be very
> complicated.

I think you don't need to process process prefixes from several groups
in the same operation.

So there should be an operation `go to group foo, process-mark some
messages, include these in the currently composed message' where foo
does not need to be the group where you're coming from.  Or something.

Maybe it would be easier to split this operation in two:
  - put these (process-marked) messages in special tmp buffer
  - include special tmp buffer in message being composed

Whatcha all think?

kai
-- 
This gubblick contains many nonsklarkish English flutzpahs,
but the overall pluggandisp can be glorked from context. -- David Moser

Re: Suggested features

[Hrvoje Niksic]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> I think you don't need to process process prefixes from several groups
> in the same operation.
> 
> So there should be an operation `go to group foo, process-mark some
> messages, include these in the currently composed message' where foo
> does not need to be the group where you're coming from.  Or something.
> 
> Maybe it would be easier to split this operation in two:
>   - put these (process-marked) messages in special tmp buffer
>   - include special tmp buffer in message being composed
> 
> Whatcha all think?

I agree with everything you said -- it would work for me.  But I'm not
Lars.  :-)

Re: Suggested features

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Maybe it would be easier to split this operation in two:
>   - put these (process-marked) messages in special tmp buffer
>   - include special tmp buffer in message being composed

Well, if we had an underlying
`message-yank-this-buffer-into-your-buffer' command, then adding such
functionality would be easy.

And we do have such a function -- `message-yank-original'.  By binding 
`message-reply-buffer' before calling it, the rest should be simple
enough.  What key should the command be bound to in the summary buffer?

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