From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: revert-buffer and changes in encoding Date: Wed, 5 Jan 2005 10:18:23 +0900 (JST) Message-ID: <200501050118.KAA12493@etlken.m17n.org> References: <200412301244.VAA28792@etlken.m17n.org> <200412302352.IAA00037@etlken.m17n.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1104887938 11988 80.91.229.6 (5 Jan 2005 01:18:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 Jan 2005 01:18:58 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 05 02:18:48 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Clzp1-0002MK-00 for ; Wed, 05 Jan 2005 02:18:47 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cm00D-0008Hx-Tc for ged-emacs-devel@m.gmane.org; Tue, 04 Jan 2005 20:30:21 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Cm003-0008HI-Lw for emacs-devel@gnu.org; Tue, 04 Jan 2005 20:30:11 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Cm001-0008GM-Vx for emacs-devel@gnu.org; Tue, 04 Jan 2005 20:30:10 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cm001-0008G5-Rv for emacs-devel@gnu.org; Tue, 04 Jan 2005 20:30:09 -0500 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1Clzoj-00076P-Aa; Tue, 04 Jan 2005 20:18:30 -0500 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.12.3/8.12.3/Debian-7.1) with ESMTP id j051IOY7019232; Wed, 5 Jan 2005 10:18:24 +0900 Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) by fs.m17n.org (8.11.6p2/8.11.6) with ESMTP id j051INq26555; Wed, 5 Jan 2005 10:18:23 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id KAA12493; Wed, 5 Jan 2005 10:18:23 +0900 (JST) Original-To: Stefan In-reply-to: (message from Stefan on Sat, 01 Jan 2005 16:28:55 -0500) X-MIME-Autoconverted: from 8bit to quoted-printable by tsukuba.m17n.org id j051IOY7019232 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:31853 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:31853 In article , Stefan writes: >>> Is that right? Wouldn't that get automatically-chosen coding system= s >>> as well as explicit user-specified coding systems? >> Yes. But, whatever coding system is used for writing a >> file, revert-buffer should read the file with the same >> coding system. > But then the name you chose is wrong. If the name is "foobar-explicit"= it > should only be non-nil if foobar was set explicitly, not automatically. Ah, ummm, I agree that the name is not good. The current semantics of that variable is "what Emacs thinks as the encoding of disk file" and the semantics of buffer-file-coding-system is "what Emacs will use by default for writing out the buffer". It seems that just file-coding-system is better than buffer-file-coding-system-explicit. > Knowing when buffer-file-coding-system was set explicitly is important = also > in select-safe-coding-system (where it should not try any other cs, inc= luding > the preferred cs). I think what important in select-safe-coding-system is whether buffer-file-coding-system has local binding or not (while treating undecided-unix as no local binding in text encoding and has local binding in eol encoding). If it has local binding, select-safe-coding-system should not try any other encoding. With that change, I think select-safe-coding-system behaves correctly in any cases. You wrote: > If I open a new file, insert =E9 and then do the following: > C-x RET f us-ascii RET > C-x C-s > the file is saved in latin-1. This is because when saving > buffer-file-coding-system is just one of several coding-systems used. > Another annoying situation is when you load a utf-8 file containing mos= tly > latin-1 chars plus a few non-latin-1 chars. Let's say you don't know t= hat > there are non-latin-1 chars and want to change the file to latin-1. Yo= u do: > C-x RET f latin-1 RET > C-x C-s > and the buffer and file is back to utf-8 !?! In both cases, with the above change, select-safe-coding-system will ask you what coding system to use while showing offending chars. > Another problem I've encountered (recently with the iso-2022-7bit -> > utf-8 -> iso-2022-7bit dance in mule-cmds.el) is that iso-2022-7bit can= not > encode eight-bit-control characters, so if you read an iso-2022-7bit fi= le > with invalid sequences in it, you get a buffer that you can't save. > Worse yet, when you try to save it it might say "selected encoding > mule-utf-8 disagrees with iso-2022-7bit-unix specified by file contents= " but > if you look at the buffer's modeline it says "J", not "u", so you wonde= r > what's up with this utf-8 thing. Whether we should allow saving such a file by iso-2022-7bit silently or not is another problem. If offending characters are only raw-bytes, how about this: Show in *Warning* buffer: As the buffer contains 8-bit characters, if you save it by iso-2022-7bit, the file won't be read back correctly by the same coding system. And ask a user: Do you really want to save it by iso-2022-7bit (y or n)? --- Ken'ichi HANDA handa@m17n.org