Uwe Brauer <[email protected]> writes:
>>> "Nick" == Nick Dokos <[email protected]> writes:
>
> > Uwe Brauer <[email protected]> writes:
> >> > The error is[fn:1]:
> >>
> >> I am sorry, this is also the fault of
> >> gnus-dired-attach
> >>
> >> Which by default uses this type of attachment, I have to look into it,
> >> how to change it on demand.
> >>
> >>
>
> > gnus-dired-attach uses mm-default-file-encoding to figure things out.
>
> I tried to generalize this function so that it optionally takes the type
> as an argument. Too complicated.
Eric Fraga has been prolific in providing solutions to these problems
today. In addition to the client side solution ("Use v instead of t")
which solves the problem on the recipient's side, he provided another
solution (which I have used in the past, but I forgot all about it until
I saw Eric's reply to your question in the gnus mailing list) that
solves the problem on the sender's side: let gnus-dired-attach default
to whatever it bloody well pleases - the attachment cookie it inserts in
the mail you are composing is just text (until you hit C-c C-c and then
it becomes a "real" attachment), so if the type is not to your liking,
you can go ahead and edit it at will (I've stripped out parts of the
cookie, so it won't be mistaken as a real attachment - I'm not sure
how to quote it so that it won't be recognized):
... type="application/octet-stream" filename="~/Desktop/foo"
disposition=attachment description=Hunoz>
to
... type="text/plain" filename="~/Desktop/foo" disposition=attachment
description=Hunoz>
Another instance of the "Your life in plain text" principle.
I thought I'd post a note with Eric's solution here, just to close the
loop all the way. Here is a reference to his reply:
http://thread.gmane.org/gmane.emacs.gnus.general/83319/focus=83320
Thanks, Eric!
--
Nick
