On Sat, 29 Jan 2011 15:11:48 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: 

>> The problem is that you don't know which SPEC keywords should be used
>> for creation and some backends may not support some keywords.  I'd
>> rather make it explicit, where there's a base list (for netrc: host user
>> protocol secret) and the user can augment it.  That's also the only way
>> to pass the default prompt, meaning a value we'd like to suggest to the
>> user but which they can override.  For example this:
>> 
>> (auth-source-search :host '("nonesuch" "twosuch") :type 'netrc :max 1
>> :create t :create-extra-keys '((A "default A") (B)))

MA> This results in 

MA> Debugger entered--Lisp error: (void-variable A)
MA>   symbol-value(A)
MA>   (and (symbol-value r) (listp (symbol-value r)))

I think I'll just keep all the values in an alist instead of setting
symbol values.  It will simplify the code, too.

MA> For me, the argument list looks a little bit ugly. Couldn't we merge at
MA> least :create and :create-extra-keys, and use keys for the extra keys?
MA> Something like

MA> (auth-source-search :host '("nonesuch" "twosuch") :type 'netrc :max 1
MA> :create '(:A "default A" :B))

MA> The value for :create could also be t, when there are no extra
MA> keys. :replace-existing could be a special key in the list, which is not
MA> added to the new entry.

You're right that it's ugly.  How about a simple alist
`auth-source-creation-defaults' that can be let-bound around the
function call?  Then the default prompts would not be necessary and we
can just have

(let ((auth-source-creation-defaults '((user "defaultUser") (A "default A"))))
  (auth-source-search :host '("nonesuch" "twosuch") :type 'netrc :max 1 
                      :create '(A B)))

which would say "If you have to prompt for the user or A, use those
default prompts.  There is no default for B but it should be in the new
entry."

That removes a lot of special cases in the arguments so I like it.  Also
it gives us a way to override the default prompt for the required keys
(host user protocol) for the netrc backend, which was not allowed before.

I think I should eliminate the :replace-existing mode.  It's confusing
to merge search and conditional creation like that.  All the :max 1
conditions were just a pain for both the library and the API user.  I'd
rather provide a deletion facility so we can say

(when (setq entry (nth 0 (auth-source-search spec)))
...
  (when (auth-source-delete entry)
     ... modify entry as needed, adding :create t or whatever else
     (setq success (apply 'auth-source-search entry))))

I put a full example for the :create option in the docs, see the
attached source below.  It's not implemented, just the docs are done.
What do you think?  I like it better, it's clear what it does and how it
does it.  Also I made creation include only the keys in :create, not any
search key.

MA> Any string works as [password-cache] key. In Tramp, I do it similar
MA> (serializing method, user, host, protocol). No big deal.

Oh, OK.  Looking at the source, I thought it was a problem.  Thanks for
explaining.

Ted