From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Uday Reddy Newsgroups: gmane.emacs.devel Subject: Re: Emacs24 coding system problems Date: Sun, 18 Nov 2012 19:06:28 +0000 Message-ID: <20649.12724.125000.858979@gargle.gargle.HOWL> References: <20627.33570.796000.901596@gargle.gargle.HOWL> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1353265605 16977 80.91.229.3 (18 Nov 2012 19:06:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Nov 2012 19:06:45 +0000 (UTC) Cc: Uday Reddy To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 18 20:06:56 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TaACm-0003rX-Cy for ged-emacs-devel@m.gmane.org; Sun, 18 Nov 2012 20:06:56 +0100 Original-Received: from localhost ([::1]:39367 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TaACc-0000ZC-61 for ged-emacs-devel@m.gmane.org; Sun, 18 Nov 2012 14:06:46 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:36344) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TaACW-0000Jb-Va for emacs-devel@gnu.org; Sun, 18 Nov 2012 14:06:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TaACT-0000Q5-G7 for emacs-devel@gnu.org; Sun, 18 Nov 2012 14:06:40 -0500 Original-Received: from sun60.bham.ac.uk ([147.188.128.137]:40602) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TaACT-0000Pv-AI for emacs-devel@gnu.org; Sun, 18 Nov 2012 14:06:37 -0500 Original-Received: from [147.188.128.127] (helo=bham.ac.uk) by sun60.bham.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1TaACQ-0004vQ-PI; Sun, 18 Nov 2012 19:06:34 +0000 Original-Received: from mx1.cs.bham.ac.uk ([147.188.192.53]) by bham.ac.uk (envelope-from ) with esmtp (Exim 4.72) id 1TaACQ-0006AR-FH using interface smart1.bham.ac.uk; Sun, 18 Nov 2012 19:06:34 +0000 Original-Received: from gromit.cs.bham.ac.uk ([147.188.193.16] helo=MARUTI.cs.bham.ac.uk) by mx1.cs.bham.ac.uk with esmtp (Exim 4.51) id 1TaACQ-0002TL-JA; Sun, 18 Nov 2012 19:06:34 +0000 In-Reply-To: , <83objg5qwk.fsf@gnu.org>, X-Mailer: VM 8.2.0b under 24.2.1 (i386-mingw-nt5.1.2600) X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 147.188.128.137 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:154926 Archived-At: Thanks for all the responses to this problem. Andreas Schwab writes: > Maybe you have a non-nil global value of coding-system-for-read, or > file-coding-system-alist is clobbered somehow. coding-system-for-read is nil. file-coding-system-alist looks the same as the normal. Eli Zaretskii writes: > Or maybe the file in question has undecodeable byte sequences. Do you > see "t" (which stands for 'raw-text') in the mode line, per chance? The files are normal unicode text. But, they appear as sequences of octets, as if they were visited by find-file-literally. There is `t' in the modeline. `buffer-file-coding-system' is getting set to `no-conversion', whereas normally it is `utf-8-unix'. These files work fine in Emacs23. The problems only arise in Emacs24. Stefan Monnier writes: > Could you have set coding-system-for-read maybe? coding-system-for-read is nil. ---- I have made some progress on narrowing down the problem. It happens only if VM is used along with emacs-w3m for displaying the HTML content. Without emacs-w3m, everything works fine. Emacs-w3m evidently does a lot of manipulations with coding-systems. But, they are only supposed to affect the interaction with the w3m sub-process. So, it is not clear why they should affect the reading of files. Indeed, in Emacs23 they didn't. If you would like to take a look at what w3m does, here is a linke to the main file: http://cvs.namazu.org/Development/emacs-w3m/w3m.el?view=log Cheers, Uday