From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: save-buffer in tar-mode Date: Thu, 12 Feb 2004 22:04:57 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200402121304.WAA11159@etlken.m17n.org> References: <20040204.135033.207583862.Takaaki.Ota@am.sony.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: sea.gmane.org 1076593672 31229 80.91.224.253 (12 Feb 2004 13:47:52 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 12 Feb 2004 13:47:52 +0000 (UTC) Cc: Takaaki.Ota@am.sony.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Feb 12 14:47:42 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ArHBu-0004II-00 for ; Thu, 12 Feb 2004 14:47:42 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ArHBu-0006k1-00 for ; Thu, 12 Feb 2004 14:47:42 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ArHAw-0007Ps-1S for emacs-devel@quimby.gnus.org; Thu, 12 Feb 2004 08:46:42 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ArH0d-0006C7-Fl for emacs-devel@gnu.org; Thu, 12 Feb 2004 08:36:03 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ArGvS-0004jU-0w for emacs-devel@gnu.org; Thu, 12 Feb 2004 08:31:13 -0500 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1ArGqb-0003rC-CR; Thu, 12 Feb 2004 08:25:41 -0500 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by mx20.gnu.org with esmtp (Exim 4.24) id 1ArGiL-000429-RX; Thu, 12 Feb 2004 08:17:10 -0500 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.6p2/3.7W-20010518204228) with ESMTP id i1CD4wd14406; Thu, 12 Feb 2004 22:04:58 +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.6p2/3.7W-20010823150639) with ESMTP id i1CD4vE25810; Thu, 12 Feb 2004 22:04:57 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id WAA11159; Thu, 12 Feb 2004 22:04:57 +0900 (JST) Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Mon, 09 Feb 2004 04:39:31 -0500) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.3 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:19882 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:19882 In article , Richard Stallman writes: > Yes. tar-mode toggles enable-multibyte-characters on saving > a file by set-buffer-multibyte and that function discards > undo info. To fix it, we must record this toggling in > buffer-undo-list. > That is one way to fix it. Another way would be to avoid changing > enable-multibyte-characters. The reason for doing so is to control > how insert-buffer copies the text. This suggests that the cleanest > approach is to define a new primitive that does exactly the kind of > copying that is desired. I think that should be easy. To avoid changing enable-multibyte-characters, I have another idea. Currently, on saving a file contained in a tar file, we toggle multibyteness twice for both the file buffer and the tar file buffer (very inefficient). The reason for toggling in the tar file buffer is that operations based on the tar information work only in unibyte buffer. And, why that operations are so is that we don't have a primitive of making buffer multibyte like the same way as string-to-multibyte. I proposed to have the same kind of primitive for a buffer long ago, but at that time, it was rejected. I'd like to propose it again, i.e., make set-buffer-multibyte accept `to' as FLAG. (set-buffer-multibyte 'to) is exactly the same as: (let ((str (string-to-multibyte (buffer-string)))) (erase-buffer) (set-buffer-multibyte t) (insert str)) Then, after we read the tar file by `no-conversion', we can make the buffer multibyte by `to'. After that, we never have to change the multibyteness. > I agree that it would be cleaner if set-buffer-multibyte did not > destroy the undo list. In principle it certainly ought to preserve > the undo list. But I think that could be a lot of work, too much > to be worth the trouble. > However, the judgment that it was too much trouble was in Emacs 20 or > so. Since then we have made substantial changes in how multibyte > encoding works. Maybe now it is not so hard. By all means think > about it. > I don't think that the planned new extension to undo-list format will > help. That could be useful for recording the set-buffer-multibyte > operation, so that it can be undone. However, the real problem is to > update the existing undo-list entries so that they still make sense. > The new kind of undo entry won't help with that. I don't understand why we have to update the existing undo-list entries. Each of them make sense in each multibyte state. So, as far as undo recovers multibyteness, they always make sense when they are referred. > Meanwhile, even if set-buffer-multibyte is fixed to correct the undo > list, the other solution (a new copy operation) would be a better way > to do this operation. The new copy operation can be simulated by something like this: (defun new-insert-buffer (buf) (let ((str (save-execursion (set-buffer buf) (buffer-string)))) (insert (if enable-multibyte-characters (string-as-multibyte str) (string-as-unibyte str))))) As it may be useful for the other case, I don't have strong objection for having such primitive. But, for tar-mode, I think the one I proposed at the head is better. --- Ken'ichi HANDA handa@m17n.org