From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Wedler, Christoph" Newsgroups: gmane.emacs.devel Subject: RE: [Bug] Issues with format.el: coding system, byte/char confusi on Date: Wed, 9 Apr 2003 20:26:32 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <67B8CED503F3D511BB9F0008C75DAD6605485576@dewdfx17> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: main.gmane.org 1049912884 26728 80.91.224.249 (9 Apr 2003 18:28:04 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 9 Apr 2003 18:28:04 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Apr 09 20:28:00 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 193KIi-0006wf-00 for ; Wed, 09 Apr 2003 20:28:00 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 193KNJ-0005dh-00 for ; Wed, 09 Apr 2003 20:32:45 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 193KJ2-0007BF-02 for emacs-devel@quimby.gnus.org; Wed, 09 Apr 2003 14:28:20 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 193KI7-0006ht-00 for emacs-devel@gnu.org; Wed, 09 Apr 2003 14:27:23 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 193KHh-0006Z6-00 for emacs-devel@gnu.org; Wed, 09 Apr 2003 14:26:57 -0400 Original-Received: from smtpde02.sap-ag.de ([155.56.68.170]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 193KHT-0006UN-00; Wed, 09 Apr 2003 14:26:44 -0400 Original-Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id UAA22675; Wed, 9 Apr 2003 20:26:53 +0200 (MESZ) Original-To: "'Kenichi Handa'" X-Mailer: Internet Mail Service (5.5.2656.59) X-SAP: out X-SAP: out Original-cc: rms@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:13084 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13084 Kenichi Handa wrote: > In article <67B8CED503F3D511BB9F0008C75DAD6605485571@dewdfx17>, "Wedler, Christoph" writes: >> I also don't think that the order is correct (if >> after-insert-file-set-buffer-file-coding-system doesn't do much, it >> might not matter): since the `buffer-file-coding-system' is used to save >> the RESULT of the format encode functions, it must be determined BEFORE >> the format-decode functions have been executed. > I agree. >>> Is there any real example where this question arises, or is it >>> purely hypothetical. >> I'm not sure since I don't know what >> `after-insert-file-set-buffer-file-coding-system' does exactly (is it >> more than eol-type handling?). > [...] So, as far as format-decode or any other functions in the > hook don't pay attention to buffer-file-coding-system X-Symbol's decode function sometimes[1] does pay attention to `buffer-file-coding-system'. (A hypothetical question became real...) > or enable-multibyte-characters, we can do the task in any order. > But, conceptually it should be done before running any other Lisp > code. It would be excellent if Emacs could be patched such that `after-insert-file-set-buffer-file-coding-system' is called directly from within Finsert_file_contents before calling Qformat_decode (instead of adding this function to `after-insert-file-functions'). - Christoph [1] with unique decoding and 8bit char use in the file: then \oe would not be decoded with a latin9 coding system, but it would be decoded with a latin1 coding system.