From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: RMAIL, MIME-related bug Date: Thu, 16 Oct 2003 10:15:26 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <2872.1066310860@www21.gmx.net> Reply-To: ttn@glug.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1066313989 31390 80.91.224.253 (16 Oct 2003 14:19:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 16 Oct 2003 14:19:49 +0000 (UTC) Cc: eliz@elta.co.il, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Oct 16 16:19:47 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AA8yh-0003VG-00 for ; Thu, 16 Oct 2003 16:19:47 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AA8yg-0006LT-00 for ; Thu, 16 Oct 2003 16:19:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AA8yR-00048S-Mx for emacs-devel@quimby.gnus.org; Thu, 16 Oct 2003 10:19:31 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AA8xt-00041D-5E for emacs-devel@gnu.org; Thu, 16 Oct 2003 10:18:57 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AA8xM-0003rU-4E for emacs-devel@gnu.org; Thu, 16 Oct 2003 10:18:56 -0400 Original-Received: from [207.245.84.69] (helo=colo.agora-net.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1AA8uX-0003AE-Vf for emacs-devel@gnu.org; Thu, 16 Oct 2003 10:15:30 -0400 Original-Received: from ttn by colo.agora-net.com with local (Exim 3.34 #1) id 1AA8uU-0003ew-00; Thu, 16 Oct 2003 10:15:26 -0400 Original-To: alexander.pohoyda@gmx.net In-reply-to: <2872.1066310860@www21.gmx.net> (alexander.pohoyda@gmx.net) 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:17152 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:17152 From: "Alexander Pohoyda" Date: Thu, 16 Oct 2003 15:27:40 +0200 (MEST) Sorry, but I do not understand what you propose here. Not to change anything because it may brake some code? no, that is an extreme position that is recognizably unworkable. i am, instead, proposing you analyze the code from a two-level perspective, the design level (high) and the implementation level (low), and change the implementation while keeping the design. here, the design is relatively (in my mind as an RMAIL user) straightforward: allow customization of which headers are visible and their ordering. to date, the implementation has been a re-rendering (copying) of the desired-visible headers to another block followed by narrowing to that block. what new implementation you choose should support the design as well as any additional criteria that have arisen since the original rmail.el was written (e.g., encoding issues). Too much code may be based on current implementation. this is something we cannot know a priori. but if we know the nature of the changes to the implementation layer, we can help fix those pieces of code that rely on it. we can do this by either retargeting the broken code to the new implementation or by retargeting the broken code to the design. the latter is preferable since, if we do a good job, the design will not change so much in the future whereas the implementation may (or may not ;-). thi