unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ted Zlatanov <tzz@lifelogs.com>
To: ding@gnus.org
Cc: emacs-devel@gnu.org
Subject: Re: Application resource storage
Date: Tue, 29 Mar 2011 16:02:15 -0500	[thread overview]
Message-ID: <87lizxej3c.fsf@lifelogs.com> (raw)
In-Reply-To: m3y63xwup8.fsf@quimbies.gnus.org

On Tue, 29 Mar 2011 22:14:11 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> 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




  reply	other threads:[~2011-03-29 21:02 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-17 17:04 Outgoing mail defaults Lars Magne Ingebrigtsen
2011-03-17 17:17 ` Ted Zlatanov
2011-03-17 17:31   ` Lars Magne Ingebrigtsen
2011-03-17 18:18     ` Ted Zlatanov
2011-03-17 18:33       ` Lars Magne Ingebrigtsen
2011-03-17 19:35         ` Ted Zlatanov
2011-03-17 17:25 ` David Reitter
2011-03-17 17:43   ` Lars Magne Ingebrigtsen
2011-03-17 18:22     ` Ted Zlatanov
2011-03-18 14:10       ` John Sullivan
2011-03-17 19:02     ` David Reitter
2011-03-17 22:27       ` chad
2011-03-18  2:38         ` Ted Zlatanov
2011-03-18  4:17           ` chad
     [not found]           ` <87bp14ntn8.fsf@topper.koldfront.dk>
2011-03-21 19:50             ` Ted Zlatanov
2011-03-17 20:57 ` Stefan Monnier
2011-03-19 19:11 ` Chong Yidong
2011-03-20  1:41   ` Ted Zlatanov
2011-03-20  3:06     ` Stefan Monnier
2011-03-20 12:20       ` Ted Zlatanov
2011-03-21 14:20         ` Stefan Monnier
2011-03-21 19:42           ` Ted Zlatanov
2011-03-21 22:14             ` Stefan Monnier
2011-03-22  2:01               ` Ted Zlatanov
2011-03-29 19:22     ` Lars Magne Ingebrigtsen
2011-03-29 19:34       ` Application resource storage (was: Outgoing mail defaults) Lars Magne Ingebrigtsen
2011-03-29 19:58         ` Application resource storage Ted Zlatanov
2011-03-29 20:14           ` Lars Magne Ingebrigtsen
2011-03-29 21:02             ` Ted Zlatanov [this message]
2011-03-29 20:51           ` chad
2011-03-29 21:23       ` Outgoing mail defaults Stefan Monnier
2011-03-22 11:26 ` Simon Josefsson
2011-04-16 16:45 ` Lars Magne Ingebrigtsen
2011-04-16 16:47   ` Lars Magne Ingebrigtsen
2011-04-16 16:51   ` Ted Zlatanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lizxej3c.fsf@lifelogs.com \
    --to=tzz@lifelogs.com \
    --cc=ding@gnus.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).