From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Francesco_Potort=C3=AC?= Newsgroups: gmane.emacs.devel Subject: Re: Rmail: new feature to deal with In-Reply-To and References headers Date: Wed, 13 Dec 2023 14:17:28 +0100 Organization: The GNU project Message-ID: <87a5qe1btj.fsf@tucano.isti.cnr.it> References: <8734w6bdoj.fsf@autistici.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4980"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, eliz@gnu.org, rameiko87@posteo.net To: Andrea Monaco Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 13 14:18:43 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rDP8N-00013w-26 for ged-emacs-devel@m.gmane-mx.org; Wed, 13 Dec 2023 14:18:43 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rDP7P-0003Da-C9; Wed, 13 Dec 2023 08:17:43 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rDP7J-0003Cw-Hf for emacs-devel@gnu.org; Wed, 13 Dec 2023 08:17:37 -0500 Original-Received: from plesklin7.if1.ehiweb.it ([79.98.45.16]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rDP7G-0006RD-1O; Wed, 13 Dec 2023 08:17:37 -0500 Original-Received: from tucano.isti.cnr.it (tucano.isti.cnr.it [146.48.81.102]) by plesklin7.if1.ehiweb.it (Postfix) with ESMTPSA id 69C86108C7A; Wed, 13 Dec 2023 14:17:28 +0100 (CET) In-Reply-To: <8734w6bdoj.fsf@autistici.org> (andrea.monaco@autistici.org) X-fingerprint: 4B02 6187 5C03 D6B1 2E31 7666 09DF 2DC9 BE21 6115 X-PPP-Message-ID: <20231213131728.16967.44694@plesklin7.if1.ehiweb.it> X-PPP-Vhost: potorti.it Received-SPF: softfail client-ip=79.98.45.16; envelope-from=pot@gnu.org; helo=plesklin7.if1.ehiweb.it X-Spam_score_int: -11 X-Spam_score: -1.2 X-Spam_bar: - X-Spam_report: (-1.2 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:313747 Archived-At: Andrea Monaco: >I don't fully understand your needs, or maybe we use slightly different >definitions of a thread. In my implementation, belonging to the same >thread is an equivalence relation: no matter which message of the thread >you start from, you always end up with the same thread; ie there's no >notion of "centering" on a given message. > >About ordering: a thread is represented as a boolean vector indexed by >message index, so the messages in a thread summary have the same >ordering, ie by the first field of the summary line (which mirrors the >ordering in the RMAIL file, I think). Well, the ordering in fact is more complex as in general there is no total = order. Unless I am missing something, a thread can be partially ordered, a= nd can be represented by a directed acyclic graph, but not generally by a l= inear array. I am not sure though that I understand the issue of centering. I added con= text below. ________________________________________________________________ Date: Sat, 09 Dec 2023 21:54:36 +0000 From: rameiko87@posteo.net To: Eli Zaretskii Cc: emacs-devel@gnu.org Subject: Re: Rmail: new feature to deal with In-Reply-To and References hea= ders > AFAIU, you should already be able to do that in Emacs 29, by using the=20 > new command rmail-summary-by-thread. After creating that summary, you=20 > can use the usual message movement commands to move between messages=20 > belonging to a thread. In fact it's not the case, because the order on the summary buffer=20 centered on a given message does not correspond in general to the=20 parents-descendants order of the thread containing that given message,=20 as defined by moving up on the References header for that message. >> Move to the previous message in the same thread as the current one=20 >> (that is, the message whose Message-ID is the last entry of the=20 >> References header, among messages in the Rmail file). Repeat argument=20 >> goes back to the n-th last entry of the References header among=20 >> messages in the Rmail file. This feature is not implemented currently unless the parents vector is=20 populated with the same order given by the References header. Someone=20 remembers how the parents vector is recursively defined in rmailsum.el? And still, going up on the chain requires regenerating the summary=20 buffer by centering every time on the parent. >> Move to the message which the current message is replying to (that is,=20 >> the message whose Message-ID appears in the In-Reply-To header), error=20 >> if not present on the Rmail file. Repeat argument iterates the command=20 >> n-times, perhaps replacing the messages which it can't find in the=20 >> Rmail file by their youngest parent. This is not implemented currently. >> Move to the first message of the thread (that is, the first entry of=20 >> the References header). With argument n, move to message number n of=20 >> the thread. >> Move to the first message of the thread (as a separate command) >> Move to the last message of the thread (that is, the last message=20 >> whose References header includes the current Message-ID). On 09.12.2023 16:49, Eli Zaretskii wrote: >> Date: Sat, 09 Dec 2023 15:35:37 +0000 >>=20 >> Rmail allows the user to move among messages by using the Subject >> header, however the In-Reply-To and References headers provide more >> accurate information about the email chain, and using them to move=20 >> along >> the conversation thread is certainly more reliable than relying on the >> Subject header. How about implementing the following commands in=20 >> Rmail: >=20 > AFAIU, you should already be able to do that in Emacs 29, by using the > new command rmail-summary-by-thread. After creating that summary, you > can use the usual message movement commands to move between messages > belonging to a thread.