From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Eli Zaretskii" Newsgroups: gmane.emacs.devel Subject: Re: Rmail changes for Emacs 22 Date: Wed, 23 Oct 2002 19:58:50 +0300 Sender: emacs-devel-admin@gnu.org Message-ID: <4634-Wed23Oct2002195850+0200-eliz@is.elta.co.il> References: <200210201940.g9KJeqW12529@rum.cs.yale.edu> <200210221432.g9MEWHa22491@rum.cs.yale.edu> <200210230957.g9N9v7K3019127@copa.pajato.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1035395852 32496 80.91.224.249 (23 Oct 2002 17:57:32 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 23 Oct 2002 17:57:32 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 184Pl4-0008Rn-00 for ; Wed, 23 Oct 2002 19:57:30 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 184Pms-0004vB-00 for ; Wed, 23 Oct 2002 19:59:22 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 184Plq-0007vk-00; Wed, 23 Oct 2002 13:58:18 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 184Pl3-0007Ex-00 for emacs-devel@gnu.org; Wed, 23 Oct 2002 13:57:29 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 184Pky-00076t-00 for emacs-devel@gnu.org; Wed, 23 Oct 2002 13:57:27 -0400 Original-Received: from balder.inter.net.il ([192.114.186.15]) by monty-python.gnu.org with esmtp (Exim 4.10) id 184Pkw-000702-00 for emacs-devel@gnu.org; Wed, 23 Oct 2002 13:57:22 -0400 Original-Received: from zaretsky ([80.230.194.148]) by balder.inter.net.il (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id BWK59173; Wed, 23 Oct 2002 19:57:11 +0200 (IST) Original-To: pmr@pajato.com X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9 In-reply-to: <200210230957.g9N9v7K3019127@copa.pajato.com> (message from Paul Michael Reilly on Wed, 23 Oct 2002 05:57:07 -0400) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:8698 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:8698 > Date: Wed, 23 Oct 2002 05:57:07 -0400 > From: Paul Michael Reilly > > 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.