From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kuehling Newsgroups: gmane.emacs.bugs Subject: Re: unibyte buffers won't display latin-1 characters Date: 29 Aug 2002 19:47:39 +0200 Sender: bug-gnu-emacs-admin@gnu.org Message-ID: <87d6s136bo.fsf@snail.pool> References: <200208291628.g7TGSgm29010@f7.net> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1030643782 8254 127.0.0.1 (29 Aug 2002 17:56:22 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 29 Aug 2002 17:56:22 +0000 (UTC) Cc: handa@etl.go.jp, bug-gnu-emacs@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 17kTWk-00028b-00 for ; Thu, 29 Aug 2002 19:56:18 +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 17kTYA-0003HN-00; Thu, 29 Aug 2002 13:57:46 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17kTXH-0003FW-00 for bug-gnu-emacs@gnu.org; Thu, 29 Aug 2002 13:56:51 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17kTXE-0003F6-00 for bug-gnu-emacs@gnu.org; Thu, 29 Aug 2002 13:56:50 -0400 Original-Received: from pop.gmx.net ([213.165.64.20] helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.10) id 17kTXE-0003F2-00 for bug-gnu-emacs@gnu.org; Thu, 29 Aug 2002 13:56:48 -0400 Original-Received: (qmail 17383 invoked by uid 0); 29 Aug 2002 17:56:46 -0000 Original-Received: from pec-160-92.tnt9.b2.uunet.de (HELO mosquito.Pool) (149.225.160.92) by mail.gmx.net (mp002-rz3) with SMTP; 29 Aug 2002 17:56:46 -0000 Original-Received: from snail (spock@snail.Pool [192.168.0.4]) by mosquito.Pool (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id TAA04266; Thu, 29 Aug 2002 19:47:37 +0200 X-Authentication-Warning: mosquito.Pool: Host spock@snail.Pool [192.168.0.4] claimed to be snail In-Reply-To: <200208291628.g7TGSgm29010@f7.net> (karl@freefriends.org) Original-To: karl@freefriends.org Original-Lines: 28 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:3359 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:3359 >>>>> "Karl" == Karl Berry writes: > Unfortunately I do not. Since compressed (or encrypted files) are > arbitrary binary data, I don't know any way to read them except with > 'no-conversion, which I assume is what stops the translation into a > multibyte buffer. `auto-compression-mode' seems to know a way around that. It loads the compressed file with coding `no-conversion' (default value of `auto-coding-alist' makes it do that), and decodes the uncompressed data into multibyte representation, determining the coding system by calling `auto-coding-alist-lookup' on the filename with the extension .gz etc stripped. Well, that's what I think after a short look at `jka-compr.el', I'm far from understanding what actually goes on there... > Anyway, at this point, I suggest that crypt++ not be loaded by default > and probably not be used at all. The builtin (un)compression and > line-ending support in emacs should suffice. Someone would have to implement a way to let `auto-compression-mode' query for passwords when required. David -- GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40