From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/70852 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: That newfangled IMAP thing... Date: Tue, 14 Sep 2010 14:26:45 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87pqwgazyi.fsf@lifelogs.com> References: <8762yd6j4j.fsf@rimspace.net> <87eid0fsil.fsf@lifelogs.com> <87bp84y00w.fsf@keller.adm.naquadah.org> <878w35ex1q.fsf@lifelogs.com> <87aanlde64.fsf@lifelogs.com> <87sk1dz236.fsf@uwo.ca> <87tylscph8.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1284492433 12882 80.91.229.12 (14 Sep 2010 19:27:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 14 Sep 2010 19:27:13 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M19225@lists.math.uh.edu Tue Sep 14 21:27:11 2010 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.69) (envelope-from ) id 1Ovb9p-0005HZ-Bb for ding-account@gmane.org; Tue, 14 Sep 2010 21:27:09 +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 1Ovb9l-0006YL-B3; Tue, 14 Sep 2010 14:27:05 -0500 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Ovb9k-0006Y8-3Y for ding@lists.math.uh.edu; Tue, 14 Sep 2010 14:27:04 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1Ovb9f-00044p-WE for ding@lists.math.uh.edu; Tue, 14 Sep 2010 14:27:03 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1Ovb9f-0004R3-00 for ; Tue, 14 Sep 2010 21:26:59 +0200 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ovb9c-0005AM-Hn for ding@gnus.org; Tue, 14 Sep 2010 21:26:56 +0200 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 ; Tue, 14 Sep 2010 21:26:56 +0200 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2010 21:26:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 39 Original-X-Complaints-To: usenet@dough.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/24.0.50 (gnu/linux) Cancel-Lock: sha1:3fM4QI8DDZ1lmGZU7E35FPRlZ3Y= X-Spam-Score: -0.7 (/) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:70852 Archived-At: On Tue, 14 Sep 2010 17:44:31 +0200 Lars Magne Ingebrigtsen wrote: LMI> Ted Zlatanov writes: >> This is so rare I wouldn't worry about it. But you could make a special >> case of "the server has NO flags BUT you have many AND you're >> about to lose them" which would require yes-or-no confirmation. I had >> the same concerns with gnus-sync.el, which is why I plan to give it a UI >> and much better merge logic. LMI> The user answers `n', and then reads a group. Gnus then sets the LMI> `gnus-forwarded' flag on an article. Then the user hits `g'. There's LMI> now one gnus-specific mark in the group, so the test doesn't trigger, LMI> and all the other marks are wiped out. :-) LMI> I think, as a first approximation, at least, that I'll just add a LMI> `dont-sync' entry in the marks list if the group doesn't support LMI> PERMANENTMARKS (for user-defined marks), and if that's present, it'll LMI> never sync those marks, even if the server later supports the marks. LMI> Perhaps. I think it's a really good idea to consider using gnus-sync.el as the way to synchronize marks at this point. Right now the backend choice is just a file name, but we could have ((server1 'native) ; nnimap internal sync (server2 "file-path") ; external file (the only option in the current gnus-sync.el) (server3 "nnimap:server1:INBOX.synchronizer") ; use an IMAP server to hold the marks (server4 nil) ; native or 'newsrc, whatever is available (server5 'newsrc) ; just newsrc.eld ) with nil (the default) equivalent to ((t nil)) meaning all servers use their native marks sync method if available and fall back to 'newsrc. If we move sync logic to a central place, we'll be able to reuse it for all backends and DTRT in a general way instead of a nnimap-specific way. nntp, nnrss, etc. could really use that. Ted