Re: bug#8050: Gnus does not connect to my IMAP server any more

Re: bug#8050: Gnus does not connect to my IMAP server any more

[Ted Zlatanov]

The following message is a courtesy copy of an article
that has been posted to gnu.emacs.bug as well.

On Tue, 15 Feb 2011 20:54:32 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> When I start Gnus, it seems to try and connect to my IMAP server but
SM> never asks for my password (which I don't save in authinfo.gpg).
SM> In just ends up saying "done", but the *Server* buffer says "offline".
SM> If I try to use O in the *Server* buffer, it switches instantly to
SM> "opened" but if I try to do anything that involves the IMAP server,
SM> I get (wrong-type-argument arrayp nil) errors because nnimap-object
SM> is nil.

I think this is fixed in the Gnus trunk as far as the auth-source
credentials go (Lars will have to fix the nnimap code failure on empty
credentials).

Now auth-source-search with :create t and :type 'netrc will ask for all
the missing data.  If the user doesn't want to add the netrc entry, it
will still work (until the password-cache times out).

I have two usability questions (cross-posting to the Gnus mailing list):

1) should we have a global override to say "never add netrc entries", or
should the prompt be Y/N/y/n instead of just y-or-n-p, or should the
save question be asked only once per file, or something else?

2) should auth-source let-bind the password-cache timeout to something
larger?  The default is pretty short and for auth-source I think at
least 30 minutes are reasonable.  It could be a customizable integer.

Thanks
Ted

Re: bug#8050: Gnus does not connect to my IMAP server any more

[Stefan Monnier]

> I think this is fixed in the Gnus trunk as far as the auth-source
> credentials go (Lars will have to fix the nnimap code failure on empty
> credentials).

I'll try again and let you know of remaining problems.

> I have two usability questions (cross-posting to the Gnus mailing list):

> 1) should we have a global override to say "never add netrc entries", or
> should the prompt be Y/N/y/n instead of just y-or-n-p, or should the
> save question be asked only once per file, or something else?

I used to always hit "y" to the question "remember the password", and
now I simply always hit "n" to the question "save the password in
.authinfo.gpg", so it's no worse than in Emacs-23.

If hitting "n" once will remember not to prompt ever again, the only
downside I can see is if someone later decides to change her mind, so we
should have a simple way to say revert the decision in the future.
Maybe the password prompt itself could somehow provide the ability to
say "RET + save", tho it's more important for this feature to be easy to
find than to be quick.

> 2) should auth-source let-bind the password-cache timeout to something
> larger?  The default is pretty short and for auth-source I think at
> least 30 minutes are reasonable.  It could be a customizable integer.

I'm not sure what this entails, but until now, Emacs has been caching my
password for the whole session (typically several days) and
I like that.  I would not want to have to re-enter my password every
half hour.


        Stefan

Re: bug#8050: Gnus does not connect to my IMAP server any more

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I think this is fixed in the Gnus trunk as far as the auth-source
> credentials go (Lars will have to fix the nnimap code failure on empty
> credentials).

What's a good test case to tickle the bug?

> I have two usability questions (cross-posting to the Gnus mailing list):
>
> 1) should we have a global override to say "never add netrc entries", or
> should the prompt be Y/N/y/n instead of just y-or-n-p, or should the
> save question be asked only once per file, or something else?

Hm...  if you look at how Firefox deals with this, it asks something
like "save password, don't save now, never save for this host", and I
think that's pretty nice, UX wise.  But there isn't a "never ask me
about saving passwords for any hosts ever again", I think?

> 2) should auth-source let-bind the password-cache timeout to something
> larger?  The default is pretty short and for auth-source I think at
> least 30 minutes are reasonable.  It could be a customizable integer.

I'd prefer a longer timeout than 30 minutes as the default.  Perhaps two
hours? 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: bug#8050: Gnus does not connect to my IMAP server any more

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> 2) should auth-source let-bind the password-cache timeout to something
>> larger?  The default is pretty short and for auth-source I think at
>> least 30 minutes are reasonable.  It could be a customizable integer.
>
> I'm not sure what this entails, but until now, Emacs has been caching my
> password for the whole session (typically several days) and
> I like that.  I would not want to have to re-enter my password every
> half hour.

If auth-source documents its usage of `password-cache-expiry' properly,
it shall be sufficient. I do not like packages, which overwrite my own
settings :-)

>         Stefan

Best regards, Michael.

Re: bug#8050: Gnus does not connect to my IMAP server any more

[Ted Zlatanov]

Stefan Monnier <monnier@iro.umontreal.ca>, Lars Magne Ingebrigtsen, and
Michael Albinus wrote:
> Ted Zlatanov wrote:
>> I have two usability questions (cross-posting to the Gnus mailing list):

>> 1) should we have a global override to say "never add netrc entries", or
>> should the prompt be Y/N/y/n instead of just y-or-n-p, or should the
>> save question be asked only once per file, or something else?

SM> I used to always hit "y" to the question "remember the password", and
SM> now I simply always hit "n" to the question "save the password in
SM> .authinfo.gpg", so it's no worse than in Emacs-23.

SM> If hitting "n" once will remember not to prompt ever again, the only
SM> downside I can see is if someone later decides to change her mind, so we
SM> should have a simple way to say revert the decision in the future.
SM> Maybe the password prompt itself could somehow provide the ability to
SM> say "RET + save", tho it's more important for this feature to be easy to
SM> find than to be quick.

LMI> Hm...  if you look at how Firefox deals with this, it asks something
LMI> like "save password, don't save now, never save for this host", and I
LMI> think that's pretty nice, UX wise.  But there isn't a "never ask me
LMI> about saving passwords for any hosts ever again", I think?

I'll leave it as it is now so it will annoy people into actually saving
their passwords and it's not too annoying.  But I'll keep this in mind
and watch for complaints.

>> 2) should auth-source let-bind the password-cache timeout to something
>> larger?  The default is pretty short and for auth-source I think at
>> least 30 minutes are reasonable.  It could be a customizable integer.

SM> I'm not sure what this entails, but until now, Emacs has been caching my
SM> password for the whole session (typically several days) and
SM> I like that.  I would not want to have to re-enter my password every
SM> half hour.

MA> If auth-source documents its usage of `password-cache-expiry' properly,
MA> it shall be sufficient. I do not like packages, which overwrite my own
MA> settings :-)

LMI> I'd prefer a longer timeout than 30 minutes as the default.  Perhaps two
LMI> hours? 

The customization would be against `auth-source-cache-expiry', which
will always be let-bound into `password-cache-expiry'.  So it will not
overwrite `password-cache-expiry', it will ignore it.  I think that's
the right thing because we're not caching passwords.  See the change I
just pushed and tell me if you disagree with it.

>> I think this is fixed in the Gnus trunk as far as the auth-source
>> credentials go (Lars will have to fix the nnimap code failure on empty
>> credentials).

LMI> What's a good test case to tickle the bug?

Make `nnimap-credentials' return (nil nil).

Ted

Re: bug#8050: Gnus does not connect to my IMAP server any more

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

>>> I think this is fixed in the Gnus trunk as far as the auth-source
>>> credentials go (Lars will have to fix the nnimap code failure on empty
>>> credentials).
>
> LMI> What's a good test case to tickle the bug?
>
> Make `nnimap-credentials' return (nil nil).

I've now fixed this part, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: bug#8050: Gnus does not connect to my IMAP server any more

[Stefan Monnier]

>>>> I think this is fixed in the Gnus trunk as far as the auth-source
>>>> credentials go (Lars will have to fix the nnimap code failure on empty
>>>> credentials).

With today's code, I could connect again, thank you.
But the prompts are poor:
- for the user name, the prompt says something like "[USER?]diro:143",
  which is very cryptic.  While I know why there's a "143" there,
  there's no reason to expect users to know that (my .gnus doesn't
  mention any port number).  Worse: I really have no clue what the "USER?"
  is about.
- for the password, the prompt again mentioned 143, which I also thing
  is not warranted.
- then I get prompted to save the password, which is the worst of the
  three:
  - the prompt is *very* long (more than 80 chars).
  - it includes the password in cleartext (WTF?).
  - none of the extra data is really something I care about when
    deciding whether I want to save my password in .authinfo.gpg.
    It's just distracting from the main issue.


-- Stefan

Re: bug#8050: Gnus does not connect to my IMAP server any more

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> But the prompts are poor:
> - for the user name, the prompt says something like "[USER?]diro:143",
>   which is very cryptic.  While I know why there's a "143" there,
>   there's no reason to expect users to know that (my .gnus doesn't
>   mention any port number).  Worse: I really have no clue what the "USER?"
>   is about.

Yes, it's quite cryptic.

The prompts should simply be

"User name for diro:imap: "

and 

"Password for diro:imap: "

Or something like that.  Well, really, the host name should be the
(real) fully qualified host name, if possible, but that may not be
feasible.

> - then I get prompted to save the password, which is the worst of the
>   three:

Yes, it should just say "Save the password for future sessions? " and
not much more.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: bug#8050: Gnus does not connect to my IMAP server any more

[Steinar Bang]

>>>>> Stefan Monnier <monnier@iro.umontreal.ca>:

>   - it includes the password in cleartext (WTF?).

That happened with HEAD from yesterday morning.  But in HEAD from
yesterday afternoon, they had been replaced with asterisks.

Re: bug#8050: Gnus does not connect to my IMAP server any more

[Ted Zlatanov]

On Thu, 17 Feb 2011 21:37:35 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> - for the user name, the prompt says something like "[USER?]diro:143",
SM>   which is very cryptic.  While I know why there's a "143" there,
SM>   there's no reason to expect users to know that (my .gnus doesn't
SM>   mention any port number).  Worse: I really have no clue what the "USER?"
SM>   is about.
SM> - for the password, the prompt again mentioned 143, which I also thing
SM>   is not warranted.
SM> - then I get prompted to save the password, which is the worst of the
SM>   three:
SM>   - the prompt is *very* long (more than 80 chars).
SM>   - it includes the password in cleartext (WTF?).

Yeah, I see now it was a mistake the way I did it.

SM>   - none of the extra data is really something I care about when
SM>     deciding whether I want to save my password in .authinfo.gpg.
SM>     It's just distracting from the main issue.

I *very much* care what goes into that file and want to see the exact
text.  So find my proposal to accomodate normal and obsessive users
alike below :)

On Fri, 18 Feb 2011 00:19:58 -0800 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> The prompts should simply be

LI> "User name for diro:imap: "

LI> and 

LI> "Password for diro:imap: "

LI> Or something like that.  Well, really, the host name should be the
LI> (real) fully qualified host name, if possible, but that may not be
LI> feasible.

OK, I'll work on improving those prompts.

>> - then I get prompted to save the password, which is the worst of the
>> three:

LI> Yes, it should just say "Save the password for future sessions? " and
LI> not much more.

How about:

"Save the $HOSTNAME password for future sessions? y/n/s/?"

where `s' shows the line we will add with the password replaced by ****?

Ted

Re: bug#8050: Gnus does not connect to my IMAP server any more

[Stefan Monnier]

>>> - then I get prompted to save the password, which is the worst of the
>>> three:
LI> Yes, it should just say "Save the password for future sessions? " and
LI> not much more.

> How about:

> "Save the $HOSTNAME password for future sessions? y/n/s/?"

The previous prompt included the ~/.authinfo.gpg file name which
I thought was good.  On the contrary, the hostname info seems redundant
since it's already been displayed by the previous 2 prompts.

> where `s' shows the line we will add with the password replaced by ****?

Here are some ways to handle the "showing the line":
1- show it in the prompt: loud, noisy, and worst of all, shows the
   password in the clear, right after you entered it via `read-passwd'
   which was careful to keep it hidden.
2- Add an `s' option to the prompt.
3- Add a second prompt (when if the user selected `y') to confirm the
   actual text that will be saved.  Can be kind of a pain for the user,
   but presumably, password aren't saved all the time.
4- not show it at all, let the user visit the file afterwards to see
   what happened if he wants to.

1 is out.  2 seems like a lot of trouble compared to using y-or-n-p
(tho, if you add an `N' option anyway to remember not to prompt next
time, the extra work is already done).  3 might be a bit annoying to
some of the users (especially those who want to save the password but
don't want to have it displayed).  4 seemed sufficient to me, but
apparently YMMV.
So yes, I'd vote for 2 or 4 (as the coder, I'd choose 4 ;-)


        Stefan

Re: bug#8050: Gnus does not connect to my IMAP server any more

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I *very much* care what goes into that file and want to see the exact
> text.  So find my proposal to accomodate normal and obsessive users
> alike below :)

I think this is like a debugging thing.  Emacs shouldn't be a platform
to debug the applications running in it.  It should just run the
applications.  :-)

As a user, I don't care, and I shouldn't care about what format the
application stores the information in.  So even putting that option in
the prompt gives a bad User eXperience, in my opinion.  It's just
confusing.

Displaying irrelevant info is almost as bad as not displaying info the
user needs.  (Note "user", not "implementer".  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: bug#8050: Gnus does not connect to my IMAP server any more

[Ted Zlatanov]

On Fri, 18 Feb 2011 17:43:13 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

SM> The previous prompt included the ~/.authinfo.gpg file name which
SM> I thought was good.  On the contrary, the hostname info seems redundant
SM> since it's already been displayed by the previous 2 prompts.

>> where `s' shows the line we will add with the password replaced by ****?

SM> Here are some ways to handle the "showing the line":
SM> 1- show it in the prompt: loud, noisy, and worst of all, shows the
SM>    password in the clear, right after you entered it via `read-passwd'
SM>    which was careful to keep it hidden.
SM> 2- Add an `s' option to the prompt.
SM> 3- Add a second prompt (when if the user selected `y') to confirm the
SM>    actual text that will be saved.  Can be kind of a pain for the user,
SM>    but presumably, password aren't saved all the time.
SM> 4- not show it at all, let the user visit the file afterwards to see
SM>    what happened if he wants to.

SM> 1 is out.  2 seems like a lot of trouble compared to using y-or-n-p
SM> (tho, if you add an `N' option anyway to remember not to prompt next
SM> time, the extra work is already done).  3 might be a bit annoying to
SM> some of the users (especially those who want to save the password but
SM> don't want to have it displayed).  4 seemed sufficient to me, but
SM> apparently YMMV.
SM> So yes, I'd vote for 2 or 4 (as the coder, I'd choose 4 ;-)

I did 2+3, asking as follows:

Add to file ~/.authinfo.gpg? (y)es/(n)o but use it/(e)dit line/(s)kip file: s

where ?e uses read-string.  I distinguish between ?n to say "don't save
but keep this info" and ?s to say "skip this file, I want to add to the
next one".  So it's one prompt, plus ?e for those who want to ensure
the data is saved correctly.

Ted

Re: bug#8050: Gnus does not connect to my IMAP server any more

[Stefan Monnier]

>> I *very much* care what goes into that file and want to see the exact
>> text.  So find my proposal to accomodate normal and obsessive users
>> alike below :)

> I think this is like a debugging thing.  Emacs shouldn't be a platform
> to debug the applications running in it.  It should just run the
> applications.  :-)

Indeed.  It's a great feature of Emacs that it is good at development an
debugging of its own code, but that shouldn't be imposed on the user.

The latest update brought in even worse behavior, BTW.  Now I get the
following prompts, in a kind of "battle for the worst prompt":
- first prompt asks me to choose the host, something like
  "host for [USER]@(diro imap.iro.umontreal.ca):(143 997 imap imap): "
  WTF?  For reference the relevant part of my gnus-secondary-select-methods
  says:
        (nnimap "diro"
                (nnimap-address "imap.iro.umontreal.ca")
                (nnimap-stream tls))

  This is a brand new prompt, which earlier Gnus could answer on its own.
- then comes the prompt for the user (which looks ugly, but at least
  makes some amount of sense, tho I guess I should change my .gnus to
  provide this info directly in gnus-secondary-select-methods).
- third prompt asks for the port to use (143 997 imap imaps).
  Again, that's a new prompt which earlier Gnus could answer on its own.
  It's slightly less hideous than the first prompt, and comes with
  the same comical completion feature (I love completion, as you may
  guess, but when it's for something which the user should not have to
  indicate at all, and for some users it's even something they don't
  know...).
- finally the real prompt for the password comes up (still looking
  pretty ugly).  Will I ever get back a simple "Password for
  monnier@diro: "?
- then comes one more prompt to ask me if I want to save the password,
  and this prompt is as long and ugly as last time, tho it at least
  keeps the password hidden (but taking up space nonetheless).
  The prompt I'd like here is just what we had ealier:
  "Save password in .authinfo.gpg?".

All those prompts are *long* which is *bad*.
I know that nowadays Emacs can usually resize the minibuffer on the fly,
but that's no reason to use long prompts which do nothing more than slow
the user down trying to figure out what the hell he's supposed to do.


        Stefan

Re: bug#8050: Gnus does not connect to my IMAP server any more

[Ted Zlatanov]

The following message is a courtesy copy of an article
that has been posted to gnu.emacs.bug as well.

On Tue, 08 Mar 2011 10:46:33 -0600 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Mon, 07 Mar 2011 18:10:38 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 
SM> - Also when I'm then asked for a password, the prompt says "Password for
SM> user foo, host bar" which is more verbose but not more clear than
SM> "Password for foo@bar" used in earlier Gnus.

>>> That's the default prompt.  Every package can supply their own which
>>> makes sense in context.  So nnimap.el could supply the password prompt
>>> "IMAP password for user %u, host %h:%p" for instance.  Does that seem OK
>>> to you?  If so I can add it to nnimap.el.

SM> I mostly care about nnimap for now because it's the only case I bumped
SM> into, but I can't imagine why it would be better to use "user foo, host
SM> bar" for the default, since all uses I can think of will want to
SM> override it with the "foo@bar" syntax instead.

TZ> This is the current default prompt list:

TZ>              (prompt (or (aget auth-source-creation-prompts r)
TZ>                          (case r
TZ>                            ('secret "%p password for user %u, host %h: ")
TZ>                            ('user "%p user name: ")
TZ>                            ('host "%p host name for user %u: ")
TZ>                            ('port "%p port for user %u and host %h: "))
TZ>                          (format "Enter %s (%%u@%%h:%%p): " r)))

TZ> Can you please propose specific replacements?

I added specific prompts for nnimap.el:

  (let* ((auth-source-creation-prompts
          '((user  . "IMAP user at %h: ")
            (secret . "IMAP password for %u@%h: ")))
...

which should look OK.  But if you or anyone else can suggest default
prompts, that would be great.

Ted

Re: bug#8050: Gnus does not connect to my IMAP server any more

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> LMI> The question that's relevant is "do you want to save the password?"
> LMI> That's the only thing a normal user could possibly be interested in, and
> LMI> it's a yes or no question.
>
> I disagree.  It's a single extra letter in a y/n prompt.  I don't see
> how it's intrusive.  You can set auth-source-never-save to t right now
> and never even see the y/n prompt.  I've accomodated all the prompting
> suggestions but I'm not removing that functionality.

It's an extra letter, but it's a completely incomprehensible extra
choice for the users.  I know that when I'm using something, I don't
want to be faced with options that I have no possible interest in.

The normal reaction to such a prompt is "oh, should I edit this?  How
should I edit this?  Do I need to edit this?"

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: bug#8050: Gnus does not connect to my IMAP server any more

[Ted Zlatanov]

On Fri, 25 Feb 2011 05:21:45 -0600 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> I disagree.  It's a single extra letter in a y/n prompt.  I don't see
TZ> how it's intrusive.  You can set auth-source-never-save to t right now
TZ> and never even see the y/n prompt.  I've accomodated all the prompting
TZ> suggestions but I'm not removing that functionality.

I changed `auth-source-never-save' to `auth-source-save-behavior' which
defaults to 'ask and allows t and nil to always and never save,
respectively.  I think it DTRT but let me know if not.

Ted

Re: bug#8050: Gnus does not connect to my IMAP server any more

[Ted Zlatanov]

On Thu, 24 Feb 2011 20:29:36 -0800 Lars Magne Ingebrigtsen <lmi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> You may want to edit the line in case you want to change it before it's
>> written.  Lars also thought this was not good but I feel strongly this
>> is useful functionality and it's not too intrusive.

LMI> I think it's definitely too intrusive.

LMI> The question that's relevant is "do you want to save the password?"
LMI> That's the only thing a normal user could possibly be interested in, and
LMI> it's a yes or no question.

I disagree.  It's a single extra letter in a y/n prompt.  I don't see
how it's intrusive.  You can set auth-source-never-save to t right now
and never even see the y/n prompt.  I've accomodated all the prompting
suggestions but I'm not removing that functionality.

LMI> Asking the user to "e"-dit the netrc line would be for Gnus to prompt
LMI> the user on `C-c C-c' "do you want to (s)end the message or (e)dit the
LMI> MIME representation of the message before sending?"  The latter is only
LMI> interesting for people who are implementing the MIME encoding, and not
LMI> any user.  The same goes for the .netrc stuff.

No, because the netrc file is not raw data but structured information.
(Although that kind of editing the raw MIME sounds very useful for
debugging and testing MIME support.)

It's like adding a command to edit the score file or having two ways to
edit the topic parameters (`G c' and `G p').  Emacs thrives on power
users; let's not oversimplify the interface.

LMI> If you want to add a debugging mode to auth-source that allows you to
LMI> edit the .netrc lines, that's fine, but it's not fine to confuse users
LMI> on something as basic as password management.

It's not confusing.  But maybe `e' should be "add the auth info and then
edit the netrc file, allowing `C-c C-c' to save it" which would be more
in line with what `G p' and score file editing do.  And then we can add
that command to Gnus and Emacs in general so you can edit your
auth-sources authinfo/netrc files quickly (in the global scope you would
have to choose the file with some extra UI).  Yeah, that sounds like
useful functionality.

Ted

Re: bug#8050: Gnus does not connect to my IMAP server any more

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> You may want to edit the line in case you want to change it before it's
> written.  Lars also thought this was not good but I feel strongly this
> is useful functionality and it's not too intrusive.

I think it's definitely too intrusive.

The question that's relevant is "do you want to save the password?"
That's the only thing a normal user could possibly be interested in, and
it's a yes or no question.

Asking the user to "e"-dit the netrc line would be for Gnus to prompt
the user on `C-c C-c' "do you want to (s)end the message or (e)dit the
MIME representation of the message before sending?"  The latter is only
interesting for people who are implementing the MIME encoding, and not
any user.  The same goes for the .netrc stuff.

If you want to add a debugging mode to auth-source that allows you to
edit the .netrc lines, that's fine, but it's not fine to confuse users
on something as basic as password management.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: bug#8050: Gnus does not connect to my IMAP server any more

[Ted Zlatanov]

On Thu, 24 Feb 2011 10:22:55 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> And when asking me whether to save the password (which it asks even
SM> tough the authentication fails :-() the prompt is again too verbose
SM> asking me

SM> "Add to .authinfo.gpg? (y)es/(n)o but use it/(e)dit line/(s)kip file"

SM> First, it's hard to parse, second I don't know what "no but use it"
SM> might mean, 

>> It means "don't write it to the file but remember the password."

SM> Just call it "(n)o", then (after all, the question is "Add to
SM> .authinfo.gpg?"); especially since you don't offer the option to not
SM> remember the password.

Should I offer that option?  I don't think it's useful.

>> You may want to edit the line in case you want to change it before it's
>> written.  Lars also thought this was not good but I feel strongly this
>> is useful functionality and it's not too intrusive.

SM> What's the advantage of editing it before (which requires this funky
SM> prompt, or an additional prompt) rather than after (which requires no
SM> special support)?  Why is Gnus the only application that finds this
SM> functionality useful enough to pester every user every time it asks for
SM> a password?

This is auth-source.el which is used by other Emacs libraries.  So it's
not a Gnus peculiarity, it's auth-source's.

I don't think the prompt is pestering.  This is supposed to be a rare
event.  You would edit the line so you don't have to edit the file
later, of course.  The special edit support here saves the user a
find-file later and doesn't interrupt the mental flow of "I entered some
info, now I want to review/edit/save/forget it."

I can add a "never edit, always save" and a "never edit, never save"
options through a customized variable to auth-source.  Would that work?

>> "Save password" does not describe what's going on fully.

SM> Why not?  Maybe the problem is that it does more.

That's not a problem.  We need to refine the prompts but I believe
auth-source.el is the only way (so far) to connect disparate storage
backends like netrc, Secrets API, and others.  The price for that
flexibility is that we don't just prompt for passwords.  If the search
has good defaults we will only prompt for passwords, e.g.

(auth-source-search :host "nonesuch" :user "tzz" :port "imap" :create t :max 1)

will prompt for just the password and the prompt will look good.

I'm trying hard to minimize the number of prompts and to streamline the
process.  I am willing to add the customizations to let users bypass the
whole process and hope it DTRT.

>> Maybe just "save to $file" would be better than "add to $file."

SM> Fine by me, tho in either case it would be good to hint at *what* is
SM> saved, so "save password" would be welcome.

"Save auth info to $file"?  We're saving authentication tokens and
connection parameters so I hope that summarizes it well.

>> The prompting could be, compared to the old 
>> "(y)es/(n)o but use it/(e)dit line/(s)kip file":

>> y/n/N/e/s/? => (y)es, save; (n)o but use the info; (N)o and don't use
>> the info and don't ask again; (e)dit the line; (s)kip this file.

>> I see two cases for (N): one, you want to use the password just entered
>> and don't want to be asked to *save* again;

SM> Yes, that would be the one I want to type.

I did this and added a ?? option.  That pops up a help window but I
think I'm doing something incorrectly because it doesn't get dismissed.
I added 

        (when (get-buffer-window bufname)
          (delete-window (get-buffer-window bufname)))

after the prompt but I think help-mode has a way to dismiss the help
window more readily.  It seems every Emacs package does this a little
differently from the others so I'm not sure what's the right way.

>> Do you think that skipping to the next file in auth-sources is not
>> useful?

SM> Definitely.

I've removed the ?s option in the prompt and pushed out the changes.

Thanks for your help.

Ted

Re: bug#8050: Gnus does not connect to my IMAP server any more

[Stefan Monnier]

SM> And when asking me whether to save the password (which it asks even
SM> tough the authentication fails :-() the prompt is again too verbose
SM> asking me

SM> "Add to .authinfo.gpg? (y)es/(n)o but use it/(e)dit line/(s)kip file"

SM> First, it's hard to parse, second I don't know what "no but use it"
SM> might mean, 

> It means "don't write it to the file but remember the password."

Just call it "(n)o", then (after all, the question is "Add to
.authinfo.gpg?"); especially since you don't offer the option to not
remember the password.

SM> I don't know what "line" I might want to "edit" (nor why it's
SM> related to saving a password), 

> authinfo/netrc files are line-based.

That's an irrelevant detail.  Obviously those files store several
passwords, so they contain a "list/set" of "entries".  Whether those
entries are represented by a single line doesn't matter (you'd still
want to be able to see/edit the whole record even if it was represented
by a multi-line chunk of text or some fixed-length binary
representation, or whathaveyou).

> You may want to edit the line in case you want to change it before it's
> written.  Lars also thought this was not good but I feel strongly this
> is useful functionality and it's not too intrusive.

What's the advantage of editing it before (which requires this funky
prompt, or an additional prompt) rather than after (which requires no
special support)?  Why is Gnus the only application that finds this
functionality useful enough to pester every user every time it asks for
a password?

SM> and neither do I know what means "skip file".
> It means "go to the next source in the auth-sources list, I don't want
> to change this one."

Then it's not "skip file" but "other file".

SM> Please make it just "Save password to .authinfo.gpg?  [y/n/N/?]"  or
SM> something short and simple like that.

> I was trying to avoid the help popup but you're right the prompt is too
> verbose.

> "Save password" does not describe what's going on fully.

Why not?  Maybe the problem is that it does more.

> Maybe just "save to $file" would be better than "add to $file."

Fine by me, tho in either case it would be good to hint at *what* is
saved, so "save password" would be welcome.

> The prompting could be, compared to the old 
> "(y)es/(n)o but use it/(e)dit line/(s)kip file":

> y/n/N/e/s/? => (y)es, save; (n)o but use the info; (N)o and don't use
> the info and don't ask again; (e)dit the line; (s)kip this file.

> I see two cases for (N): one, you want to use the password just entered
> and don't want to be asked to *save* again;

Yes, that would be the one I want to type.

> two, you don't want to use the password

I don't know what that could mean.  The user has just gone through the
trouble of typing the password, so surely she wants to use it somehow.
The other N I can think of is "don't remember this password even in this
session", which corresponds to one of the 2 options in Emacs-23 (where
you had no option to save the password, but you had to choose between
"save for the session" or "not save for the session").

> Do you think that skipping to the next file in auth-sources is not
> useful?

Definitely.


        Stefan

Re: bug#8050: Gnus does not connect to my IMAP server any more

[Ted Zlatanov]

The following message is a courtesy copy of an article
that has been posted to gnu.emacs.bug as well.

On Wed, 23 Feb 2011 20:03:10 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> The new code shows much fewer prompts, but now I can't connect any more.
SM> The problem is that among the prompts it doesn't show me any more, the
SM> "username" prompt is now missing, so Gnus then asks me

SM>  "Password for [any user]@(imap.iro.umontreal.ca diro):(143 997 imap imaps): "

This is fixed.  I have a patch coming which will also ask for the user
name and any other parameters.

SM> And when asking me whether to save the password (which it asks even
SM> tough the authentication fails :-() the prompt is again too verbose
SM> asking me

SM>  "Add to .authinfo.gpg? (y)es/(n)o but use it/(e)dit line/(s)kip file"

SM> First, it's hard to parse, second I don't know what "no but use it"
SM> might mean, 

It means "don't write it to the file but remember the password."

SM> I don't know what "line" I might want to "edit" (nor why it's
SM> related to saving a password), 

authinfo/netrc files are line-based.  auth-source manages more than
passwords: in addition you may be adding host, port, user name, and
other tokens.

You may want to edit the line in case you want to change it before it's
written.  Lars also thought this was not good but I feel strongly this
is useful functionality and it's not too intrusive.

SM> and neither do I know what means "skip file".

It means "go to the next source in the auth-sources list, I don't want
to change this one."

SM> Please make it just "Save password to .authinfo.gpg?  [y/n/N/?]"  or
SM> something short and simple like that.

I was trying to avoid the help popup but you're right the prompt is too
verbose.

"Save password" does not describe what's going on fully.  Maybe just
"save to $file" would be better than "add to $file."

The prompting could be, compared to the old 
"(y)es/(n)o but use it/(e)dit line/(s)kip file":

y/n/N/e/s/? => (y)es, save; (n)o but use the info; (N)o and don't use
the info and don't ask again; (e)dit the line; (s)kip this file.

I see two cases for (N): one, you want to use the password just entered
and don't want to be asked to *save* again; two, you don't want to use
the password and don't want auth-source to ask you *anything* again,
including password prompts.  Is either choice what you had in mind with
(N) in your suggestion?

Do you think that skipping to the next file in auth-sources is not
useful?  It doesn't take up too much space in the prompt to add a 's'
option...  But I'm overthinking it, perhaps.

Thanks for the suggestions
Ted