From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/78219 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general,gmane.emacs.devel Subject: Re: Application resource storage Date: Tue, 29 Mar 2011 16:02:15 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87lizxej3c.fsf@lifelogs.com> References: <87d3ln9b7y.fsf@stupidchicken.com> <87aagqsh4e.fsf@lifelogs.com> <87y63xem1c.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1301432588 27422 80.91.229.12 (29 Mar 2011 21:03:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 29 Mar 2011 21:03:08 +0000 (UTC) Cc: emacs-devel@gnu.org To: ding@gnus.org Original-X-From: ding-owner+M26529@lists.math.uh.edu Tue Mar 29 23:03:04 2011 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 1Q4g48-00060t-CY for ding-account@gmane.org; Tue, 29 Mar 2011 23:03:04 +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 1Q4g3l-00062f-Dv; Tue, 29 Mar 2011 16:02:41 -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 1Q4g3k-00062Q-3g for ding@lists.math.uh.edu; Tue, 29 Mar 2011 16:02:40 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1Q4g3b-0002Kx-0l for ding@lists.math.uh.edu; Tue, 29 Mar 2011 16:02:35 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1Q4g3a-00048K-9e for ding@gnus.org; Tue, 29 Mar 2011 23:02:30 +0200 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Q4g3Y-0005l1-VX for ding@gnus.org; Tue, 29 Mar 2011 23:02:28 +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, 29 Mar 2011 23:02:28 +0200 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Mar 2011 23:02:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 47 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.110016 (No Gnus v0.16) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:hXOmpNnqd51yGLxPNdx8jzv0Ztc= X-Spam-Score: -0.7 (/) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:78219 gmane.emacs.devel:137874 Archived-At: On Tue, 29 Mar 2011 22:14:11 +0200 Lars Magne Ingebrigtsen wrote: LMI> Ted Zlatanov writes: >> I think you're describing an assistant.el walkthrough. Right now the >> assistants store their return in an artificial data structure but the >> walkthrough with the user decisions and answers could *be* the data >> structure (it's a decision tree, right?) LMI> Yes, that would be a use case. There are other things that this could LMI> be used for that I've been missing -- for instance, now when nnimap LMI> connects to a server, it tries both the imap and the imaps port. If LMI> nnimap could stash what the successful port was, and try that first the LMI> next time, the next startup would be slightly faster. LMI> Not particularly essential, but there's a lot of stuff like that that LMI> could be done trivially if there was a place to stash this data... Something like: (preferred (imap (servers ("serverA" :port 587) ("serverB" :port 1957)))) would be a nice way to remember this data. The trick is to make this data also the one that an assistant.el walkthrough would generate. >> As a global Emacs facility it would be easy to make all these strings >> part of a big global-registry alist, which can then be customized and >> saved independently. But I think it would squash the decision tree from >> assistant.el into unwieldy string representations of the nodes and edges. LMI> True. But it's basically what Firefox does with its data, if you look LMI> under about:config. I think that would be a step backwards considering the available Lisp facilities. It would be pretty easy to generate these strings dynamically and let the user edit them: Prefs -> IMAP -> Servers -> [serverA] -> [port 587] -> [serverB] -> [port 1957] [+] or some such interface. But going backwards, where we decide on these magical strings to express "the port and name for the Gnus IMAP serverA" and only store the strings, is harder and less flexible because you have to write the printer and the reader+parser. Ted