From: Uwe Brauer <oub@mat.ucm.es>
To: ding@gnus.org
Subject: Re: change content type of attachment before sending
Date: Mon, 02 Nov 2015 13:56:09 +0000 [thread overview]
Message-ID: <87611kbj46.fsf@mat.ucm.es> (raw)
In-Reply-To: <87k2q0zxxz.fsf@delle7240.chemeng.ucl.ac.uk>
>>> "Eric" == Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> On Sunday, 1 Nov 2015 at 17:25, Uwe Brauer wrote: [...]
>> But what if I don't know the type? The beauty of the interactive
>> call is that it offers various possibilities which I never
>> remember by heart.
> I am confused. In your OP, you said you wanted to erroneously set
> the type, e.g. to application/octet-stream. Either you know what
> you want to set to (erroneously) or the problem is a more
> fundamental one in your mailcap settings? That is, if I
> misunderstood you and you in fact want to correct erroneous file
> types, the problem is not with mml-xxx but with your system's
> settings which mml uses to determine file types.
Ok here is the longer story. It concerns Xemacs and GNU emacs, tex files
and latin-1 and UTF-8 encoding.
Xemacs 21.5.X still uses Mule, while GNU emacs has moved to UFT-8
internally as far as I know.
Now the problem is the following:
- I send a latex file with latin-1 chars, buffer coding is set to
latin-1, via gnus as text/x-tex type to a Xemacs user: the
coding is corrupted.
- I send a latex file with latin-1 chars, buffer coding is set to
UTF-8, via gnus as text/x-tex type to a Xemacs user: the
coding is ok.
Now
- the user sends it back, but now it is the other way around: if he
sends using buffer coding is set to latin-1 via gnus as text/x-tex type
to me: the coding is ok
- The user sends it back, buffer coding is set to
UTF-8 via gnus as text/x-tex type me: the
coding is corrupted.
GNU emacs ---UTF8-> Xemacs OK
Xemacs ---latin-1-> GNU emacs ok
The problem can be circumvent using application/octet-stream then both
buffer codings are fine.
But I don't want that for every latex file.
That is why I want to be able to change the mml type, in case I made a
mistake, or using the dired function (since this much more comfortable
to use) which would allow me to chose the coding
Uwe Brauer
next prev parent reply other threads:[~2015-11-02 13:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-01 8:31 Uwe Brauer
2015-11-01 9:19 ` Andreas Schwab
2015-11-01 14:50 ` Uwe Brauer
2015-11-01 14:56 ` Adam Sjøgren
2015-11-01 17:25 ` Uwe Brauer
2015-11-01 17:49 ` Adam Sjøgren
2015-11-01 19:59 ` Uwe Brauer
2015-11-01 20:18 ` Adam Sjøgren
2015-11-02 7:02 ` Eric S Fraga
2015-11-02 13:56 ` Uwe Brauer [this message]
2015-11-02 16:34 ` Eric S Fraga
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87611kbj46.fsf@mat.ucm.es \
--to=oub@mat.ucm.es \
--cc=ding@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).