Re: auth-source.el rewrite

[Michael Albinus <michael.albinus@gmx.de>]

Ted Zlatanov <tzz@lifelogs.com> writes:

> MA> Is it necessary to pass them as list with the keyword :create-extra-keys?
> MA> Just allow them to be added to SPEC, and if they don't belong to the
> MA> well known keywords, they are ignored during search, and used during
> MA> creation.
>
> 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)))

This results in 

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

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

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

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

> MA> What about using password-cache? If a user does not like password
> MA> caching (for security reasons, or so), she could set password-cache to nil.
>
> MA> There is no need for an additional auth-source-do-cache then.
>
> Hmmm.  But we're caching more than the password.  It could work if the
> key was not required to be a valid symbol name, so it could be a
> serialized SPEC (the value doesn't have any restrictions).  Right now
> password-cache-* won't work.

Any string works as key. In Tramp, I do it similar (serializing method,
user, host, protocol). No big deal.

> Ted

Best regards, Michael.