From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: very slow archive-mode Date: Fri, 14 Mar 2008 03:03:35 +0200 Organization: JURTA Message-ID: <87k5k6qjp8.fsf@jurta.org> References: <200803122247.58553.pogonyshev@gmx.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1205457267 12367 80.91.229.12 (14 Mar 2008 01:14:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Mar 2008 01:14:27 +0000 (UTC) Cc: pogonyshev@gmx.net, Stefan Monnier , emacs-devel@gnu.org To: Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 14 02:14:55 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JZyVb-0004dm-6O for ged-emacs-devel@m.gmane.org; Fri, 14 Mar 2008 02:14:55 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JZyV1-0007Kk-Uq for ged-emacs-devel@m.gmane.org; Thu, 13 Mar 2008 21:14:20 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JZySd-0006Gm-Q3 for emacs-devel@gnu.org; Thu, 13 Mar 2008 21:11:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JZySb-0006FE-Fw for emacs-devel@gnu.org; Thu, 13 Mar 2008 21:11:50 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JZySb-0006F1-9P for emacs-devel@gnu.org; Thu, 13 Mar 2008 21:11:49 -0400 Original-Received: from relay02.kiev.sovam.com ([62.64.120.197]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JZySb-0005aK-50 for emacs-devel@gnu.org; Thu, 13 Mar 2008 21:11:49 -0400 Original-Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay02.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1JZySV-000GHK-OE; Fri, 14 Mar 2008 03:11:44 +0200 In-Reply-To: (Kenichi Handa's message of "Thu, 13 Mar 2008 16:51:34 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-unknown-linux-gnu) X-Scanner-Signature: d0b3bc0b24c4067239780ad28ae5b444 X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2413 [Mar 14 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {HEADERS: header Content-Type found without required header Content-Transfer-Encoding} X-SpamTest-Method: none X-SpamTest-Rate: 11 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release X-detected-kernel: by monty-python.gnu.org: FreeBSD 6.x (1) 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: news.gmane.org gmane.emacs.devel:92463 Archived-At: > As I've just found a bug in handling > no-conversion-multibyte, I'll fix it soon. After that, I am > going to change auto-coding-alist to use > no-conversion-multibyte for archive files, and adjust > arc-mode and tar-mode. > > What do you think? Thanks in advance for starting to fix this problem. I think it is important not to let a buffer associated with the archive file to stay in the modified state after interrupting its loading. Using a separate unibyte buffer may be a good solution, but there is one possible problem: it would be difficult to find this hidden separate buffer to kill it with the purpose to free up the memory occupied by the file buffer after interrupting its loading (perhaps, this buffer can be killed using unwind-protect during loading and kill-buffer-hook for C-x k). So it seems a separate unibyte buffer would be necessary only if it will be impossible to get the fast reading without leaving the file buffer in the modified state. PS. Fortunately, I had a copy of the corrupted archive on a DVD, so nothing was lost, but nevertheless this is a damaging problem. -- Juri Linkov http://www.jurta.org/emacs/