From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: Documentation of nnoo.el Date: Fri, 25 Dec 2015 11:44:14 +0800 Message-ID: <87lh8jtcoh.fsf@ericabrahamsen.net> References: <87615q88kh.fsf@ericabrahamsen.net> <87k2u66nvx.fsf@ericabrahamsen.net> <87pp3w4vfn.fsf@ericabrahamsen.net> <8760znu6jq.fsf@gnus.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1451015082 26128 80.91.229.3 (25 Dec 2015 03:44:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Dec 2015 03:44:42 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 25 04:44:33 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aCJIv-0000HG-IX for ged-emacs-devel@m.gmane.org; Fri, 25 Dec 2015 04:44:33 +0100 Original-Received: from localhost ([::1]:34077 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aCJIu-00048D-Pp for ged-emacs-devel@m.gmane.org; Thu, 24 Dec 2015 22:44:32 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aCJIo-00047B-He for emacs-devel@gnu.org; Thu, 24 Dec 2015 22:44:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aCJIj-0007ne-Rr for emacs-devel@gnu.org; Thu, 24 Dec 2015 22:44:26 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:40664) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aCJIj-0007nU-LY for emacs-devel@gnu.org; Thu, 24 Dec 2015 22:44:21 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aCJIi-0008L1-Ab for emacs-devel@gnu.org; Fri, 25 Dec 2015 04:44:20 +0100 Original-Received: from 111.197.157.87 ([111.197.157.87]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Dec 2015 04:44:20 +0100 Original-Received: from eric by 111.197.157.87 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Dec 2015 04:44:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 66 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 111.197.157.87 User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1.50 (gnu/linux) Cancel-Lock: sha1:alVwYzHxGD/9xYscK56Tha6td+k= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:196809 Archived-At: Lars Ingebrigtsen writes: > Eric Abrahamsen writes: > >> Does this mean you'd rather not go all the way with EIEIO? Maybe just >> vectors or something? > > EIEIO would be fine by me... > >> Well that's the real crux, isn't it :) I'm happy to try banging together >> a preliminary example of how it might look. I don't think rewriting the >> backends would be as much work as adjusting pretty much everything else >> to use the new code. > > Well, every reference to a server variable in the backends would need to > be rewritten as an object access instead, so there would be quite a lot > of churn on the backend side, too. I kinda thing there wouldn't be as > much on the Gnus side... Sure -- I guess it's bound to be a whole lot of tweaking no matter what. >>>> 1. First, only make backends into classes. This would give us the chance >>>> to do away with the select-method/secondary-select-method >>>> distinction, and just have a list of defined servers. >>> >>> I think that's a totally orthogonal issue. We could do that now, but >>> it'd break the current naming scheme for the groups in Gnus. >> >> It is orthogonal, but on the other hand it would take extra effort to >> preserve. Do you mean the "nnml+ServerName:GroupName" scheme? I don't >> quite see how doing away with the primary/secondary distinction would >> affect that... > > Groups from primary servers aren't prefixed, while groups from > non-primary servers are... Ah, right. I guess I still don't see why it would be so terrible to lose that distinction, though... Taking a step back, there are two general structural alterations I'd like to suggest. The first is splitting up the .newsrc.eld file a bit: right now it's sort of kitchen-sink, and feels fragile. If servers were classes, we could use eieio-persistent to write the server definitions to one file, and keep marks in a different file (written there by a different backend). Group definitions/parameters could go in the same file as the server definitions. This would make the server/group file somewhat user editable, at least user readable, while the marks backend would be hands-off. Things like the topic topology could go in a third file. The other proposal is the agent. I'm imagining the agent as a mix-in class for server backends. It would have many of the same methods as the servers, and would wait in the background until a server signaled a denied/no-connection/I'm-broken error. The agent would then set the server's "status" slot to closed or denied, and the agent's methods would check for that status and take over the action. That would allow the agent to potentially usurp any server functionality that the server itself was unable to perform. Lastly, there's the problem that EIEIO seems to still be in flux, and an EIEIO version of Gnus would probably only work reliably with Emacs master. Anyway, all this is totally pie in the sky! But worth discussing, I think. Eric