From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Emacs 22 branch created. Date: Mon, 30 Apr 2007 18:09:46 -0400 Message-ID: References: <871wi9jw37.fsf@catnip.gol.com> <462E7B94.3000008@gnu.org> <462F0A07.50104@gnu.org> <864pn4an8j.fsf@lola.quinscape.zz> <86zm4w97du.fsf@lola.quinscape.zz> <20070425195026.GA19472@printf.se> <20070427133832.22F374DD5F@rocksteady.printf.se> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1177971426 7346 80.91.229.12 (30 Apr 2007 22:17:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 30 Apr 2007 22:17:06 +0000 (UTC) Cc: henrik.enberg@telia.com, eliz@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 01 00:17:04 2007 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 1HieB5-0004yQ-JW for ged-emacs-devel@m.gmane.org; Tue, 01 May 2007 00:17:03 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HieHJ-0005Wi-GX for ged-emacs-devel@m.gmane.org; Mon, 30 Apr 2007 18:23:29 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HieD1-0001iw-C2 for emacs-devel@gnu.org; Mon, 30 Apr 2007 18:19:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HieD0-0001iJ-Ge for emacs-devel@gnu.org; Mon, 30 Apr 2007 18:19:02 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HieD0-0001iD-8p for emacs-devel@gnu.org; Mon, 30 Apr 2007 18:19:02 -0400 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Hie6l-0003AT-E3 for emacs-devel@gnu.org; Mon, 30 Apr 2007 18:12:35 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1Hie42-000248-Ru; Mon, 30 Apr 2007 18:09:46 -0400 In-reply-to: (message from Stefan Monnier on Sun, 29 Apr 2007 20:45:16 -0400) X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) 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:70429 Archived-At: The non-decoded part of the buffer should be in unibyte mode. Why does it have to be in unibyte mode? Decoding can be done in a multibyte buffer. And of course very inefficient when you'll constantly be editing a very large rmail buffer. Not really, because the gap makes such operations efficient. > We could have a new feature to omit part of the buffer when saving the > file. Rmail could use it so that this copy is not saved. This > feature should not affect auto-saving. If you need such a low-level hack, I think it's a good indication that you're headed for a bad solution. The other approach also needs peculiar changes in lower-level features to work right. Various operations on the message buffer would have to operate on the file buffer as well. These include set-buffer-file-name, rename-buffer, as well as saving. - you assume that a MIME message has only one "main text". It may have several, with "inlined attachments" in-between (e.g. images). Some of the attachments may contain text which you may want to display as well. All solvable of course, just an indication that your optimization will work less often and will be a potential source of more bugs. This has no effect on the validity of this optimization. Rmail does not handle attachments now. We might want to implement support for displaying attachments, but if we display them in separate buffers, the optimization won't interfere. If we wanted to make Rmail decode text attachments in the same buffer, that too can work easily enough together with this optimization. So I think there is no difficulty, really.