From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.bugs Subject: Re: unibyte buffers won't display latin-1 characters Date: Tue, 27 Aug 2002 10:20:04 +0900 (JST) Sender: bug-gnu-emacs-admin@gnu.org Message-ID: <200208270120.KAA28563@etlken.m17n.org> References: <873ct4ughi.fsf@snail.pool> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1030411193 6676 127.0.0.1 (27 Aug 2002 01:19:53 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 27 Aug 2002 01:19:53 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org, karl@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17jV1L-0001j3-00 for ; Tue, 27 Aug 2002 03:19:51 +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 17jV2f-0007VV-00; Mon, 26 Aug 2002 21:21:13 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17jV1j-0007Ue-00 for bug-gnu-emacs@gnu.org; Mon, 26 Aug 2002 21:20:15 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17jV1g-0007US-00 for bug-gnu-emacs@gnu.org; Mon, 26 Aug 2002 21:20:14 -0400 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17jV1g-0007UN-00; Mon, 26 Aug 2002 21:20:12 -0400 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.6/3.7W-20010518204228) with ESMTP id g7R1K5l25228; Tue, 27 Aug 2002 10:20:05 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) by fs.m17n.org (8.11.3/3.7W-20010823150639) with ESMTP id g7R1K5920383; Tue, 27 Aug 2002 10:20:05 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id KAA28563; Tue, 27 Aug 2002 10:20:04 +0900 (JST) Original-To: dvdkhlng@gmx.de In-Reply-To: <873ct4ughi.fsf@snail.pool> (message from David Kuehling on 24 Aug 2002 22:52:25 +0200) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.1.30 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) Errors-To: bug-gnu-emacs-admin@gnu.org X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Bug reports for GNU Emacs, the Swiss army knife of text editors List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.bugs:3312 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:3312 I included Karl in CC: because it seems that the current problem is related to cyrpt++. In article <873ct4ughi.fsf@snail.pool>, David Kuehling writes: > Even if this is a small problem, the question remains, why gzipped files > are opened as unibyte. This is extremely inconvenient. I think that > also keeps me from reading japanese info files which are (in my Debian > Woody system) by default gzipped. Emacs only displays them properly > when I gunzip them. > The hole problem also applys to crypt++. I've just tried crypt++ Ver.2.90. When I load it, on reading a compressed file, it is automatically decompressed even if auto-compression-mode is turned off. And, in that case, I confirmed that the file is read into a unibyte buffer without any code conversion. But, when I turned on auto-compression-mode, the file is read into a multibyte buffer with normal code convesion. Karl, the comment of cyrpt++.el says that you are the maintainer. Do you know how to fix this problem? Here's a reply to the other bug. > Unfortunately I can't get Emacs > to display latin-1 characters in unibyte buffers, although the > documentation states that this is possible. For that, I've just installed the attached fix in HEAD and RC. Could you please try it? --- Ken'ichi HANDA handa@etl.go.jp 2002-08-27 Kenichi Handa * xdisp.c (get_next_display_element): In unibyte case, don't use octal form for such eight-bit characters that can be converted to multibyte char. Index: xdisp.c =================================================================== RCS file: /cvs/emacs/src/xdisp.c,v retrieving revision 1.777 retrieving revision 1.778 diff -u -c -r1.777 -r1.778 cvs server: conflicting specifications of output style *** xdisp.c 22 Aug 2002 16:52:56 -0000 1.777 --- xdisp.c 27 Aug 2002 00:59:55 -0000 1.778 *************** *** 4258,4271 **** the translation. This could easily be changed but I don't believe that it is worth doing. ! Non-printable multibyte characters are also translated ! octal form. */ ! else if ((it->c < ' ' && (it->area != TEXT_AREA || (it->c != '\n' && it->c != '\t'))) ! || (it->c >= 127 ! && it->len == 1) ! || !CHAR_PRINTABLE_P (it->c)) { /* IT->c is a control character which must be displayed either as '\003' or as `^C' where the '\\' and '^' --- 4258,4279 ---- the translation. This could easily be changed but I don't believe that it is worth doing. ! If it->multibyte_p is nonzero, eight-bit characters and ! non-printable multibyte characters are also translated to ! octal form. ! ! If it->multibyte_p is zero, eight-bit characters that ! don't have corresponding multibyte char code are also ! translated to octal form. */ ! else if (((it->c < ' ' || it->c == 127) && (it->area != TEXT_AREA || (it->c != '\n' && it->c != '\t'))) ! || (it->multibyte_p ! ? ((it->c >= 127 ! && it->len == 1) ! || !CHAR_PRINTABLE_P (it->c)) ! : (it->c >= 128 ! && it->c == unibyte_char_to_multibyte (it->c)))) { /* IT->c is a control character which must be displayed either as '\003' or as `^C' where the '\\' and '^'