unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Eli Zaretskii" <eliz@is.elta.co.il>
Cc: emacs-devel@gnu.org
Subject: Re: Rmail changes for Emacs 22
Date: Wed, 23 Oct 2002 19:58:50 +0300	[thread overview]
Message-ID: <4634-Wed23Oct2002195850+0200-eliz@is.elta.co.il> (raw)
In-Reply-To: <200210230957.g9N9v7K3019127@copa.pajato.com> (message from Paul Michael Reilly on Wed, 23 Oct 2002 05:57:07 -0400)

> Date: Wed, 23 Oct 2002 05:57:07 -0400
> From: Paul Michael Reilly <pmr@pajato.com>
> 
> I'm not sure that it is totally obvious, but AFAICS there are TWO
> distinct coding system issues.  First is the message based decoding
> that everyone seems to recognize that is necessary to view messages.
> Second is the coding system used for mail file/buffer.  They are
> mostly orthogonal.

??? It is customary in Emacs that after decoding text we set the
buffer's file coding system to what was used to decode the text.
That's what RMAIL does today when it decodes and displays a message:
the (narrowed) buffer's buffer-file-coding-system is set to the
coding system used to decode the message.

So, unless I grossly misunderstand what you wanted to say, the two
issues you mentioned are not at all orthogonal, they are more like one
and the same.

> The mail buffer coding system will be dynamic.  It should mostly be
> iso-latin1 according to mail rfcs but Users will tend to abuse the
> specs so Rmail needs to be robust enough to handle that abuse.  How
> exactly remains to be decided.

Why not use what RMAIL does today: it looks at the charset= header,
and if that's absent, guesses using the user settings, the defaults,
and the encoding-detection routines (in that order)?

> Editing of messages opens up a huge can of worms wrt coding system.
> If anyone can state a sensible and effective policy for dealing with
> coding system conflicts while editing messages, more power to 'em.

Assuming normal usage, I don't see why we should deviate from the
normal policy used for saving buffers to disk files.  Emacs already
has machinery to deal with mixed charsets in a buffer, including
prompting the user for choosing the encoding if Emacs unable to
decide.

In general, as I've said elsewhere in this thread, I think Emacs
should encode each message in its original encoding (given by
charset=).  There are some exceptions to that rule (which I also
mentioned), but I'd suggest first to agree on the rule.

> It is easy to foresee Users changing message headers
> and bodies in ways that would render a message unmailable and/or
> unviewable in another mail agent but are nevertheless doable within
> Emacs.

Emacs gives you enough rope to hang yourself.  I won't worry too much
about those who do.

  reply	other threads:[~2002-10-23 16:58 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <rzqu1jseva6.fsf@albion.dl.ac.uk>
2002-10-13  4:08 ` Rmail changes for Emacs 22 Richard Stallman
2002-10-15 17:40   ` Dave Love
2002-10-16  4:38     ` Richard Stallman
2002-10-16  6:09       ` Eli Zaretskii
2002-10-16  7:19         ` Kenichi Handa
2002-10-19  4:25           ` Paul Michael Reilly
2002-10-19  4:55           ` Richard Stallman
2002-10-20  7:03             ` Eli Zaretskii
2002-10-18 22:59         ` Richard Stallman
2002-10-20 19:40           ` Stefan Monnier
2002-10-22  3:12             ` Richard Stallman
2002-10-22  6:33               ` Kai Großjohann
2002-10-22 18:48                 ` Eli Zaretskii
2002-10-22 14:32               ` Stefan Monnier
2002-10-23  7:12                 ` Richard Stallman
2002-10-23  8:13                   ` Kenichi Handa
2002-10-25  5:36                     ` Richard Stallman
2002-10-23  9:57                   ` Paul Michael Reilly
2002-10-23 16:58                     ` Eli Zaretskii [this message]
2002-10-24  7:29                       ` Stefan Monnier
2002-10-24 17:30                         ` Eli Zaretskii
2002-10-21 15:33         ` Dave Love
2002-10-21 16:37           ` Kai Großjohann
2002-10-21 20:50             ` Stefan Monnier
2002-10-22  6:28               ` Kai Großjohann
2002-10-22  6:31         ` Kai Großjohann
2002-10-22 18:40           ` Eli Zaretskii
2002-10-23  5:24             ` Kai Großjohann
2002-10-16 12:21       ` Paul Michael Reilly
2002-10-19  4:56         ` Richard Stallman
2002-10-21 15:34       ` Dave Love
2002-10-22 16:36         ` Richard Stallman
2002-10-24 21:37           ` Dave Love
2002-10-16  4:38     ` Richard Stallman
2002-10-21 15:31       ` Dave Love

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4634-Wed23Oct2002195850+0200-eliz@is.elta.co.il \
    --to=eliz@is.elta.co.il \
    --cc=emacs-devel@gnu.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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).