VM

Comment 5 for bug 744001

Revision history for this message
Tim Cross (tcross) wrote : Re: [Bug 744001] Re: reply from the sent-to address

One of the nice things about pcrisis is that in addition to being able to
apply some heuristics to determine who the mail should appear from, you can
also choose a specific 'profile' per message or easily change what pcrisis
is automatically using.

Aa to the interface - well, I think its fine if your customizing it via ..vm
(thats how I did it). I would need to look at its support for customize to
determine if we could provide an easier wayt o do a basic configuration.
With respect to its interface with VM, I've had no problems with it - it
just sort of works for me. I cannot think of any issues I have had which I
thought needed to be improved. A lot may depend on what individual
requirements are - I wouldn't say I'm a power user of the package.

Possibly the main improvement would be to add to the documentation - maybe
add some basic recipes for setting up a really basic configuration and maybe
some examples of more advanced configurations. The pcrisis package is
extremely powerful - what took me the longest was just understanding how it
all fit together and realizing for my setup, I didn't need all the bells and
whistles. Once I broke it down to just what I needed, it was surprisingly
simple - initially, it was a little hard to see the wood for the trees.
Maybe a basic recipe or two would help with that. However, I must point out
that it was over 6 years ago that I did this setup and I've not had to
change it since (actually, in recent months I removed my pcrisis
configuration to maintain a stripped down config while I worked on other VM
issues). One of the problems with packages that are this reliable is that
you tend to forget the gory details!

Note that I'm not saying we should not add this sort of functionality into
core VM, only that doing so in a reliable and clean way is non-trivial and
that currently, VM does have this functionality via pcrisis, which is/has
been used by a number of people for quite some time. My recommendation would
be to use pcrisis for a while. This is likely to give a better position for
evaluating whether we can either integrate it better or add a 'light-weight'
solution that may be easier to use (possibly by borrowing ideas from pcrisis
and improving on them). I will try to find time to restore my old
configuraiton and see if there are any issues with current VM or Emacs 24
and try to refresh my memory regarding the package and some of the issues
involved in getting this right.

Tim

On Tue, Mar 29, 2011 at 2:54 PM, Arik <email address hidden> wrote:

> Hey Tim,
>
> Thanks for the info. I will take a closer look at pcrisis and see what I
> can do with it. Your right that the Delivered-To header is unreliable,
> but its true too that the To: and Cc: could be unreliable in this sense
> too (additionally there would need to be a sanity check that it is
> choosing a sensible address from the To: lists - one you own), for
> instance if I got a mail to both addresses but I was looking at it in
> the mailbox associated with one and wanted to reply from there I would
> have a 50% chance of disappointment. Not sure if that's really a common
> real world example...
>
> What are your thoughts, as a user of this functionality, on whether they
> should be absorbed? Is there a need for a better interface to them?
>
> --
> You received this bug notification because you are subscribed to VM.
> https://bugs.launchpad.net/bugs/744001
>
> Title:
> reply from the sent-to address
>
> Status in VM (View Mail) for Emacs:
> Triaged
>
> Bug description:
> This is a feature request. It would be useful to have an option like
> vm-reply-from-recipient-address (or so) that will insert a "From:"
> header with the address to which the email was sent. This is useful in
> cases where a vm user has multiple mailboxes for different addresses
> in the same session, where only one can be the 'user-mail-address'.
> This can be done in such a way that a from header will not be inserted
> if the default is appropriate.
>