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: Sun, 27 Dec 2015 09:03:35 +0800 Message-ID: <87fuyoog7s.fsf@ericabrahamsen.net> References: <87615q88kh.fsf@ericabrahamsen.net> <87k2u66nvx.fsf@ericabrahamsen.net> <87pp3w4vfn.fsf@ericabrahamsen.net> <8760znu6jq.fsf@gnus.org> <87lh8jtcoh.fsf@ericabrahamsen.net> <87h9j4oo6h.fsf@gnus.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1451178258 29027 80.91.229.3 (27 Dec 2015 01:04:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Dec 2015 01:04:18 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 27 02:04:09 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 1aCzkm-0000Tu-MW for ged-emacs-devel@m.gmane.org; Sun, 27 Dec 2015 02:04:08 +0100 Original-Received: from localhost ([::1]:40460 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aCzkm-0002ET-4p for ged-emacs-devel@m.gmane.org; Sat, 26 Dec 2015 20:04:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48768) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aCzkU-0002Ad-0Y for emacs-devel@gnu.org; Sat, 26 Dec 2015 20:03:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aCzkQ-0006wm-7I for emacs-devel@gnu.org; Sat, 26 Dec 2015 20:03:49 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:44149) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aCzkQ-0006wc-08 for emacs-devel@gnu.org; Sat, 26 Dec 2015 20:03:46 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aCzkL-0008M5-RC for emacs-devel@gnu.org; Sun, 27 Dec 2015 02:03:42 +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 ; Sun, 27 Dec 2015 02:03:41 +0100 Original-Received: from eric by 111.197.157.87 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 Dec 2015 02:03:41 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 60 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:vU+Ea8gXoXxP1OtILeqUln6kvOc= 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:196946 Archived-At: Lars Ingebrigtsen writes: > Eric Abrahamsen writes: > >>> 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... > > It's not terrible -- it's just incompatible. :-) Fair enough. >> 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. > > Actually, I think it's too transparent. :-) It almost looks > user-editable, which makes people edit it, and things blow up. It's > also a cop-out, because we can say "well, just edit the file" instead of > providing proper interfaces to the data. > > It's not like Firefox users open Firefox data files in an editor and > start typing away... Well I don't think we disagree here -- .newsrc.eld is a bit dangerous, for multiple reasons. If marks were stored in a separate file, we could tell users the file was binary and scare them away from opening it :) There are already proper interfaces to editing the data, and an EIEIO version wouldn't change that. It would even add (ugh) a customize interface for doing the editing, if that's your thing. But at the same time, the server/group definitions file would be much more human-readable, if people insisted on looking at it, and much harder to break in mysterious ways. >> 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. > > I think you've pretty much described how the Agent works now. :-) That's the point! I don't want to change how anything works, just how it's implemented. All I was saying is that the Agent lends itself very nicely to generic functions and method composition. Anyhow, it's maybe not worth trying to have an extended discussion about this now, when it's all sort of nebulous, and I'm so unlikely to produce any code right away. Maybe in the next few months, if I come up with a basic "code sketch", I can post it here or on gnus.general and people can see what they think? Yrs, Eric