Gnus development mailing list
 help / color / mirror / Atom feed
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 




  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).