From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/67555 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: nnimap article editing Date: Thu, 09 Oct 2008 12:21:44 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <86skr5r8ev.fsf@lifelogs.com> References: <86bpxtsx1k.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1223573076 15834 80.91.229.12 (9 Oct 2008 17:24:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Oct 2008 17:24:36 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M16006@lists.math.uh.edu Thu Oct 09 19:25:34 2008 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.50) id 1KnzFD-0002Bi-21 for ding-account@gmane.org; Thu, 09 Oct 2008 19:24:11 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1KnzD6-0005cq-F1; Thu, 09 Oct 2008 12:22:00 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1KnzD5-0005ce-9q for ding@lists.math.uh.edu; Thu, 09 Oct 2008 12:21:59 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.69) (envelope-from ) id 1KnzD2-0001MW-C7 for ding@lists.math.uh.edu; Thu, 09 Oct 2008 12:21:59 -0500 Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1KnzD5-0005XA-00 for ; Thu, 09 Oct 2008 19:21:59 +0200 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KnzCx-0002OP-WD for ding@gnus.org; Thu, 09 Oct 2008 17:21:52 +0000 Original-Received: from 38.98.147.130 ([38.98.147.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Oct 2008 17:21:51 +0000 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Oct 2008 17:21:51 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 51 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.130 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6;d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (gnu/linux) Cancel-Lock: sha1:jf89VpQhiDk9we4PbEUwt6t3hGA= X-Spam-Score: -1.5 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:67555 Archived-At: On Thu, 09 Oct 2008 16:58:51 +0200 David Engster wrote: DE> Ted Zlatanov writes: >> This, if implemented, would work for any backend that accepts articles, >> not just nnimap. DE> OK, so you're talking about implementing an alternative to article DE> editing through delete-and-create, without touching nnimap at all? I DE> understood the original posting to implement DE> nnimap-request-replace-article, which would be necessary for editing DE> articles in nnimap like e.g. in nnml groups, which just cannot be DE> done for IMAP, at least not according to the specification given in DE> the manual ("remove ARTICLE (which is a number) from GROUP and DE> insert BUFFER there instead"). Right, it would be BACKEND-request-replace-or-supersede-article (whatever name people like) which would fall back to BACKEND-request-replace-article if that was available. >> I don't see a problem with sorting or caching. Expire the old article, >> that's all. The new one should have the same Message-ID but otherwise >> can be completely different. DE> The problem I see is that the article number would change while the DE> article is displayed. Hence, after editing, Gnus would have to at least DE> quit the summary buffer, rescan the group, and then re-enter the summary DE> to display the edited article. I think that's reasonable, and probably can be done faster once the basic operation works reliably. DE> Users who use the *-by-number functions for sorting will probably DE> see edited articles as most recent, but that's indeed a small DE> issue. I think it's actually the expected behavior--users would expect the sort to be by modification time, not creation time. We can use the registry to link the Message-ID to the creation time if necessary, it's not hard, but I doubt many will care. DE> As for caching (and the agent), I don't know if they depend in any DE> way on a mapping between UID and Message-ID? If not, it shouldn't be DE> a problem. In any case, I admit having an article editing solution DE> like this is better than none at all. I think the only part of Gnus that really cares about the Message-ID is the registry. Everything else goes by article number (based on what I've seen in the code). Maybe someone that knows the agent and caching can explain better. Ted