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

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

[Stefan Monnier]

Package: Emacs
Version: 24.0.50

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

The *Message* buffer says:

auth-source-search: found 2 backends matching (:max 1 :host "news2.teksavvy.com" :port ("119" "nntp"))
auth-source-search: found 0 results (max 1/1) in [object auth-source-backend "~/.authinfo.gpg" netrc "~/.authinfo.gpg" t t t auth-source-netrc-create auth-source-netrc-search] matching (:max 1 :host "news2.teksavvy.com" :port ("119" "nntp"))
auth-source-search: found 0 results (max 1/1) in [object auth-source-backend "~/.authinfo" netrc "~/.authinfo" t t t auth-source-netrc-create auth-source-netrc-search] matching (:max 1 :host "news2.teksavvy.com" :port ("119" "nntp"))
Reading /home/monnier/var/newsrc.eld...
Checking new news...
Opening connection to imap.iro.umontreal.ca via tls...
Opening TLS connection to `imap.iro.umontreal.ca'...
Opening TLS connection with `gnutls-cli --insecure -p imaps imap.iro.umontreal.ca'...done
Opening TLS connection to `imap.iro.umontreal.ca'...done
auth-source-search: found 2 backends matching (:max 1 :host ("diro" "imap.iro.umontreal.ca") :port ("143" "993" "imap" "imaps") :create nil)
auth-source-search: found 0 results (max 1/1) in [object auth-source-backend "~/.authinfo.gpg" netrc "~/.authinfo.gpg" t t t auth-source-netrc-create auth-source-netrc-search] matching (:max 1 :host ("diro" "imap.iro.umontreal.ca") :port ("143" "993" "imap" "imaps") :create nil)
auth-source-search: found 0 results (max 1/1) in [object auth-source-backend "~/.authinfo" netrc "~/.authinfo" t t t auth-source-netrc-create auth-source-netrc-search] matching (:max 1 :host ("diro" "imap.iro.umontreal.ca") :port ("143" "993" "imap" "imaps") :create nil)
auth-source-search: found 2 backends matching (:max 1 :host "news.gmane.org" :port ("119" "nntp"))
auth-source-search: found 0 results (max 1/1) in [object auth-source-backend "~/.authinfo.gpg" netrc "~/.authinfo.gpg" t t t auth-source-netrc-create auth-source-netrc-search] matching (:max 1 :host "news.gmane.org" :port ("119" "nntp"))
auth-source-search: found 0 results (max 1/1) in [object auth-source-backend "~/.authinfo" netrc "~/.authinfo" t t t auth-source-netrc-create auth-source-netrc-search] matching (:max 1 :host "news.gmane.org" :port ("119" "nntp"))
Reading active file from eso via nntp...
Opening nntp server on eso...
auth-source-search: found 2 backends matching (:max 1 :host "news.eternal-september.org" :port ("119" "nntp"))
auth-source-search: found 0 results (max 1/1) in [object auth-source-backend "~/.authinfo.gpg" netrc "~/.authinfo.gpg" t t t auth-source-netrc-create auth-source-netrc-search] matching (:max 1 :host "news.eternal-september.org" :port ("119" "nntp"))
auth-source-search: found 0 results (max 1/1) in [object auth-source-backend "~/.authinfo" netrc "~/.authinfo" t t t auth-source-netrc-create auth-source-netrc-search] matching (:max 1 :host "news.eternal-september.org" :port ("119" "nntp"))
Opening nntp server on eso...done
Reading active file from diro via nnimap...done
Reading active file via nndraft...done
Checking new news...done




In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2011-02-15 on pastel
Windowing system distributor `The X.Org Foundation', version 11.0.10707000
configured using `configure  '--enable-maintainer-mode' 'CFLAGS=-Wall -Wno-pointer-sign -DUSE_LISP_UNION_TYPE -DSYNC_INPUT -DENABLE_CHECKING -DXASSERTS -DFONTSET_DEBUG -g -O1 -I/usr/include/GNUstep' '--with-x-toolkit=lucid''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: fr_CH.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Group

Minor modes in effect:
  gnus-undo-mode: t
  electric-pair-mode: t
  electric-indent-mode: t
  url-handler-mode: t
  global-reveal-mode: t
  reveal-mode: t
  auto-insert-mode: t
  savehist-mode: t
  minibuffer-electric-default-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
^ <down> <down> <down> <down> O <up> C <up> O <up> 
C-x 5 b * M e <tab> <return> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> q <switch-frame> 
<switch-frame> <switch-frame> <switch-frame> <switch-frame> 
<switch-frame> M-x r e p - e m - b u <tab> <return
>

Recent messages:
Reading active file from diro via nnimap...done
Reading active file via nndraft...done
Checking new news...done
Opening connection to imap.iro.umontreal.ca via tls...
Opening TLS connection to `imap.iro.umontreal.ca'...
Opening TLS connection with `gnutls-cli --insecure -p imaps imap.iro.umontreal.ca'...done
Opening TLS connection to `imap.iro.umontreal.ca'...done
auth-source-search: found 2 backends matching (:max 1 :host ("diro" "imap.iro.umontreal.ca") :port ("143" "993" "imap" "imaps") :create nil)
auth-source-search: found 0 results (max 1/1) in [object auth-source-backend "~/.authinfo.gpg" netrc "~/.authinfo.gpg" t t t auth-source-netrc-create auth-source-netrc-search] matching (:max 1 :host ("diro" "imap.iro.umontreal.ca") :port ("143" "993" "imap" "imaps") :create nil)
auth-source-search: found 0 results (max 1/1) in [object auth-source-backend "~/.authinfo" netrc "~/.authinfo" t t t auth-source-netrc-create auth-source-netrc-search] matching (:max 1 :host ("diro" "imap.iro.umontreal.ca") :port ("143" "993" "imap" "imaps") :create nil)

Load-path shadows:
/usr/share/emacs23/site-lisp/bbdb/bbdb hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb
/usr/share/emacs23/site-lisp/bbdb/bbdb-mhe hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-mhe
/usr/share/emacs23/site-lisp/bbdb/bbdb-gnus hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-gnus
/usr/share/emacs23/site-lisp/bbdb/bbdb-migrate hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-migrate
/usr/share/emacs23/site-lisp/bbdb/bbdb-sc hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-sc
/usr/share/emacs23/site-lisp/bbdb/bbdb-snarf hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-snarf
/usr/share/emacs23/site-lisp/bbdb/bbdb-w3 hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-w3
/usr/share/emacs23/site-lisp/bbdb/bbdb-gui hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-gui
/usr/share/emacs23/site-lisp/bbdb/bbdb-print hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-print
/usr/share/emacs23/site-lisp/bbdb/bbdb-rmail hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-rmail
/usr/share/emacs23/site-lisp/bbdb/bbdb-vm hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-vm
/usr/share/emacs23/site-lisp/bbdb/bbdb-ftp hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-ftp
/usr/share/emacs23/site-lisp/bbdb/bbdb-merge hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-merge
/usr/share/emacs23/site-lisp/bbdb/bbdb-whois hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-whois
/usr/share/emacs23/site-lisp/bbdb/bbdb-com hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-com
/usr/share/emacs23/site-lisp/bbdb/bbdb-hooks hides /usr/share/emacs/site-lisp/bbdb/lisp/bbdb-hooks

Features:
(shadow sort mail-extr emacsbug url-util nnfolder nndraft nnmh nnagent
nnml nnimap parse-time utf7 gnus-agent gnus-srvr gnus-score score-mode
nnvirtual gnus-msg gnus-art mm-uu mml2015 epg-config mm-view mml-smime
smime dig mailcap nntp proto-stream starttls tls gnus-cache nnir
gnus-sum macroexp nnoo gnus-group gnus-undo nnmail mail-source
format-spec server gnus-start gnus-spec gnus-int gnus-range message
sendmail rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader
gnus-win gnus gnus-ems nnheader mail-utils wid-edit noutline outline
easy-mmode flyspell ispell eldoc checkdoc regexp-opt thingatpt help-mode
easymenu view prog-mode electric url-handlers url-parse auth-source
warnings eieio byte-opt bytecomp byte-compile assoc netrc gnus-util
time-date password-cache url-vars mm-util mail-prsvr reveal autoinsert
uniquify advice help-fns advice-preload savehist minibuf-eldef cl
cl-loaddefs proof-site proof-autoloads pg-vars bbdb-autoloads agda2
tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar
dnd fontset image fringe lisp-mode register page newcomment menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face files text-properties overlay md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote
make-network-process dbusbind dynamic-setting system-font-setting
font-render-setting x-toolkit x multi-tty emacs)

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

[Ted Zlatanov]

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

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

[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]

On Tue, 22 Feb 2011 17:46:56 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

SM> - finally the real prompt for the password comes up (still looking
SM>   pretty ugly).  Will I ever get back a simple "Password for
SM>   monnier@diro: "?
SM> - then comes one more prompt to ask me if I want to save the password,
SM>   and this prompt is as long and ugly as last time, tho it at least
SM>   keeps the password hidden (but taking up space nonetheless).
SM>   The prompt I'd like here is just what we had ealier:
SM>   "Save password in .authinfo.gpg?".

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

I think you'll be happier with the latest auth-source.el which is in the
Gnus trunk.  I don't know when it will be synchronized to the Emacs
trunk, sorry.

Ted

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

[Stefan Monnier]

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

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

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

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

First, it's hard to parse, second I don't know what "no but use it"
might mean, I don't know what "line" I might want to "edit" (nor why
it's related to saving a password), and neither do I know what means
"skip file".  Please make it just "Save password to .authinfo.gpg? [y/n/N/?]"
or something short and simple like that.


        Stefan

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

[Ted Zlatanov]

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

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]

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

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 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

[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

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

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 107 bytes --]

Sending my replies as a digest.  They didn't show up after a few hours;
sorry if you see duplicates.

Ted


[-- Attachment #2.1: Type: message/rfc822, Size: 200 bytes --]

Subject: Topics

Topics:
   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

[-- Attachment #2.2: Type: message/rfc822, Size: 2637 bytes --]

From: Ted Zlatanov <tzz@lifelogs.com>
To: ding@gnus.org
Cc: bug-gnu-emacs@gnu.org
Subject: Re: bug#8050: Gnus does not connect to my IMAP server any more
Date: Fri, 25 Feb 2011 05:21:45 -0600
Message-ID: <87hbbs4awm.fsf@lifelogs.com>

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





[-- Attachment #2.3: Type: message/rfc822, Size: 1022 bytes --]

From: Ted Zlatanov <tzz@lifelogs.com>
To: ding@gnus.org
Cc: bug-gnu-emacs@gnu.org
Subject: Re: bug#8050: Gnus does not connect to my IMAP server any more
Date: Fri, 25 Feb 2011 05:50:24 -0600
Message-ID: <87zkpk2v0f.fsf@lifelogs.com>

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





[-- Attachment #3: Type: text/plain, Size: 5 bytes --]


-- 

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

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

[Stefan Monnier]

The saga continues:

Now I'm not asked for a host name and a port any more (just realized in
the mean time that those questions were not only unexpected but even
subtler than I thought since they're not about how/where to connect (the
connection is already established at that point) but about which
password to use).  Good.

- But when I'm asked for a user name there is no default, whereas earlier
  my local user name was used as default (which happens to work for me on
  most of the machines to which I can connect).  Please use the local user
  name as default in that prompt.

- Also when I'm then asked for a password, the prompt says "Password for
  user foo, host bar" which is more verbose but not more clear than
  "Password for foo@bar" used in earlier Gnus.

- I'm asked whether to save the password regardless of whether the
  password and user names are correct or not.  That's really bad.

- When I was asked whether to save my password, the cursor was not shown in
  the prompt, which looked weird.  Maybe it was a temporary redisplay
  problem (I hit `n' mechanically pretty quickly, so maybe Emacs didn't
  have time to display the cursor).
  
- If the connection fails (e.g. bad password or bad user name), I don't
  get asked again, instead Gnus continues in offline mode.

- After refusing to save the password in authinfo.gpg, I get a message
  along the lines of "auth-source-search: CREATED 1 results ...".
  I don't care whether "results" is replaced by "result" when there's
  only 1, but this looks like a debug message which should disappear.
  Usually, I'd assume it is just a forgotten debug message, but given
  the atrocious prompts I've seen in this thread, I'm a bit
  more cautious.


-- Stefan

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

[Ted Zlatanov]

On Sat, 05 Mar 2011 15:13:53 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> - But when I'm asked for a user name there is no default, whereas earlier
SM>   my local user name was used as default (which happens to work for me on
SM>   most of the machines to which I can connect).  Please use the local user
SM>   name as default in that prompt.

I'll add that.  I thought I did but must have forgotten.

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'm asked whether to save the password regardless of whether the
SM>   password and user names are correct or not.  That's really bad.

auth-source.el doesn't know at that time whether the authentication will
be successful.  I think you're saying we need an `auth-source-save'
function to be called after the fact instead of a ":create t" parameter.

But what about the case where the server is down and yet you know the
password is good?  Do we throw it away?

SM> - When I was asked whether to save my password, the cursor was not shown in
SM>   the prompt, which looked weird.  Maybe it was a temporary redisplay
SM>   problem (I hit `n' mechanically pretty quickly, so maybe Emacs didn't
SM>   have time to display the cursor).

I'm not sure about that one, I'm just using `read-passwd'.
  
SM> - If the connection fails (e.g. bad password or bad user name), I don't
SM>   get asked again, instead Gnus continues in offline mode.

nnimap.el could use `auth-source-forget+' and then retry that query.
But as above, I think you're saying we need to save/cache AFTER
authentication success.

SM> - After refusing to save the password in authinfo.gpg, I get a message
SM>   along the lines of "auth-source-search: CREATED 1 results ...".
SM>   I don't care whether "results" is replaced by "result" when there's
SM>   only 1, but this looks like a debug message which should disappear.

I think it makes sense to show confirmation that we just added to your
passwords.  It's a rare event and deserves notice.

Hiding it by default is quite easy, if you feel strongly about it.  I don't.

Thanks for the help, as always.

Ted

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

[Stefan Monnier]

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.

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

SM> - I'm asked whether to save the password regardless of whether the
SM> password and user names are correct or not.  That's really bad.

> auth-source.el doesn't know at that time whether the authentication will
> be successful.  I think you're saying we need an `auth-source-save'
> function to be called after the fact instead of a ":create t" parameter.

Yes.

> But what about the case where the server is down and yet you know the
> password is good?  Do we throw it away?

Yes.  I *never* know that the password is good (maybe I'm
a pathologically poor typist, but I can't be the only one who's been
surprised a few times to see his password rejected even tho he thought
it was typed properly).

SM> - When I was asked whether to save my password, the cursor was not shown in
SM> the prompt, which looked weird.  Maybe it was a temporary redisplay
SM> problem (I hit `n' mechanically pretty quickly, so maybe Emacs didn't
SM> have time to display the cursor).

> I'm not sure about that one, I'm just using `read-passwd'.

No, you misread: I'm talking about the prompt to save the password
(i.e. the one with y/n/N/e/?), not the prompt to read the password.
  
SM> - If the connection fails (e.g. bad password or bad user name), I don't
SM> get asked again, instead Gnus continues in offline mode.

> nnimap.el could use `auth-source-forget+' and then retry that query.
> But as above, I think you're saying we need to save/cache AFTER
> authentication success.

Yes, fixing the previous one might fix this one, I just know this also
needs to work right.

SM> - After refusing to save the password in authinfo.gpg, I get a message
SM> along the lines of "auth-source-search: CREATED 1 results ...".
SM> I don't care whether "results" is replaced by "result" when there's
SM> only 1, but this looks like a debug message which should disappear.
> I think it makes sense to show confirmation that we just added to your
> passwords.  It's a rare event and deserves notice.

Two things:
1- then make it look nice, like "Saved password for foo@bar into <file>".
   The current text really looks like debug output.
2- I just replied "n" before, so I did *not* want it saved (tho I do
   want it saved for the session), so it is not a rare event at all.


        Stefan

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

[Ted Zlatanov]

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.

This is the current default prompt list:

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

Can you please propose specific replacements?

SM> - I'm asked whether to save the password regardless of whether the
SM> password and user names are correct or not.  That's really bad.

>> auth-source.el doesn't know at that time whether the authentication will
>> be successful.  I think you're saying we need an `auth-source-save'
>> function to be called after the fact instead of a ":create t" parameter.

SM> Yes.

I'll put something in.  This makes sense but is extra work for the
auth-source API users, unfortunately.

SM> - When I was asked whether to save my password, the cursor was not shown in
SM> the prompt, which looked weird.  Maybe it was a temporary redisplay
SM> problem (I hit `n' mechanically pretty quickly, so maybe Emacs didn't
SM> have time to display the cursor).

>> I'm not sure about that one, I'm just using `read-passwd'.

SM> No, you misread: I'm talking about the prompt to save the password
SM> (i.e. the one with y/n/N/e/?), not the prompt to read the password.

It uses:

        (while (not done)
          (message "%s" prompt)
          (setq k (read-char))
          ...)
  
SM> - If the connection fails (e.g. bad password or bad user name), I don't
SM> get asked again, instead Gnus continues in offline mode.

OK, I'll add logic to the nnimap wrapper.

SM> - After refusing to save the password in authinfo.gpg, I get a message
SM> along the lines of "auth-source-search: CREATED 1 results ...".
SM> I don't care whether "results" is replaced by "result" when there's
SM> only 1, but this looks like a debug message which should disappear.
>> I think it makes sense to show confirmation that we just added to your
>> passwords.  It's a rare event and deserves notice.

SM> Two things:
SM> 1- then make it look nice, like "Saved password for foo@bar into <file>".
SM>    The current text really looks like debug output.

All the output from auth-source starts with the function name.  The line
you mention can be put in the background in favor of the output you
specified.  But, again, auth-source does NOT just save passwords, and
there's no guarantee that a host or a port were specified.  So the
message will look different.

SM> 2- I just replied "n" before, so I did *not* want it saved (tho I do
SM>    want it saved for the session), so it is not a rare event at all.

OK, I'll show it only when the data is saved.

Ted

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

[Ted Zlatanov]

On Mon, 07 Mar 2011 12:23:59 -0600 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Sat, 05 Mar 2011 15:13:53 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 
SM> - But when I'm asked for a user name there is no default, whereas earlier
SM> my local user name was used as default (which happens to work for me on
SM> most of the machines to which I can connect).  Please use the local user
SM> name as default in that prompt.

TZ> I'll add that.  I thought I did but must have forgotten.

This is done.

SM> - I'm asked whether to save the password regardless of whether the
SM> password and user names are correct or not.  That's really bad.

TZ> auth-source.el doesn't know at that time whether the authentication will
TZ> be successful.  I think you're saying we need an `auth-source-save'
TZ> function to be called after the fact instead of a ":create t" parameter.

I added this as part of the auth result.  So you can say (example from
nnimap.el, where the 3rd element of the credentials is the
:save-function property of the search result):

                    (when (functionp (nth 2 credentials))
                      (funcall (nth 2 credentials)))

after a successful login.

This means that everyone using the ":create t" parameter will have to
adjust for the :save-function.  Currently that's just nnimap.el and
sieve-manage.el (which I'll modify when you and Lars agree this is the
right approach).

SM> - After refusing to save the password in authinfo.gpg, I get a message
SM> along the lines of "auth-source-search: CREATED 1 results ...".
SM> I don't care whether "results" is replaced by "result" when there's
SM> only 1, but this looks like a debug message which should disappear.

OK, it's gone.  But we show a shorter one with `message'
unconditionally, which I think is the right thing to do.

Ted

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

[Ted Zlatanov]

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

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

[Stefan Monnier]

>                          (case r
>                            ('secret "%p password for user %u, host %h: ")
>                            ('user "%p user name: ")
>                            ('host "%p host name for user %u: ")
>                            ('port "%p port for user %u and host %h: "))
>                          (format "Enter %s (%%u@%%h:%%p): " r)))

> Can you please propose specific replacements?

         (case r
           (secret "%p password for %u@%h: ")
           (user "%p user name for %h: ")
           (host "%p host name for user %u: ")
           (port "%p port for %u@%h: "))
         (format "Enter %s (%%u@%%h:%%p): " r)))

Notes:
- I added the host name to the user prompt (usually the user name
  may be different in different hosts for the same user, so most such
  prompts do include a hostname/realm).
- I left the user name in the host prompt, even though that sounds
  backward to me (kind of like choosing the street number before the
  street name).
- I removed the quotes which just made each of the branches be
  acceptable when `r' has value `quote'.
         
> I'll put something in.  This makes sense but is extra work for the
> auth-source API users, unfortunately.

I know, but the difference in user experience is enormous.

>>> I'm not sure about that one, I'm just using `read-passwd'.

SM> No, you misread: I'm talking about the prompt to save the password
SM> (i.e. the one with y/n/N/e/?), not the prompt to read the password.

> It uses:
>         (while (not done)
>           (message "%s" prompt)
>           (setq k (read-char))
>           ...)

And that leads to an absence of cursor in the minibuffer, even though
it's fundamentally a prompt.  Why not copy y-or-n-p from subr.el as
a starting point?
If you can factor out the commonality, I'd be happy to provide
a "prompt-maker" function and then define y-or-n-p in terms of that
prompt-maker.

SM> Two things:
SM> 1- then make it look nice, like "Saved password for foo@bar into <file>".
SM> The current text really looks like debug output.
> All the output from auth-source starts with the function name.

I call that debug output and is not OK for normal messages.

> The line you mention can be put in the background in favor of the
> output you specified.  But, again, auth-source does NOT just save
> passwords, and there's no guarantee that a host or a port were
> specified.  So the message will look different.

The case where a user and host were specified is likely to be the main
one for most users, so it's worth handling it specially.

SM> 2- I just replied "n" before, so I did *not* want it saved (tho I do
SM> want it saved for the session), so it is not a rare event at all.
> OK, I'll show it only when the data is saved.

Good, thank you.


        Stefan

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

[Ted Zlatanov]

On Tue, 08 Mar 2011 16:34:53 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

>> (case r
>> ('secret "%p password for user %u, host %h: ")
>> ('user "%p user name: ")
>> ('host "%p host name for user %u: ")
>> ('port "%p port for user %u and host %h: "))
>> (format "Enter %s (%%u@%%h:%%p): " r)))

>> Can you please propose specific replacements?

SM>          (case r
SM>            (secret "%p password for %u@%h: ")
SM>            (user "%p user name for %h: ")
SM>            (host "%p host name for user %u: ")
SM>            (port "%p port for %u@%h: "))
SM>          (format "Enter %s (%%u@%%h:%%p): " r)))

Great, thanks.  I added this.

SM> Notes:
SM> - I added the host name to the user prompt (usually the user name
SM>   may be different in different hosts for the same user, so most such
SM>   prompts do include a hostname/realm).
SM> - I left the user name in the host prompt, even though that sounds
SM>   backward to me (kind of like choosing the street number before the
SM>   street name).

That's the best we can do with default prompts.  The caller should use
something better since they know what they need already.

SM> - I removed the quotes which just made each of the branches be
SM>   acceptable when `r' has value `quote'.

Heh, I didn't see that.  Thanks for catching it.
         
>> I'll put something in.  This makes sense but is extra work for the
>> auth-source API users, unfortunately.

SM> I know, but the difference in user experience is enormous.

You're right, and thanks for making me do it right :)

>> It uses:
>> (while (not done)
>> (message "%s" prompt)
>> (setq k (read-char))
>> ...)

SM> And that leads to an absence of cursor in the minibuffer, even though
SM> it's fundamentally a prompt.  Why not copy y-or-n-p from subr.el as
SM> a starting point?
SM> If you can factor out the commonality, I'd be happy to provide
SM> a "prompt-maker" function and then define y-or-n-p in terms of that
SM> prompt-maker.

Can I really be the only one to need this?  Weird.  I actually used
`read-char-choice' first but XEmacs doesn't support it.  Perhaps Gnus
should provide a compatibility wrapper that uses it opportunistically.
Would you rather go the "prompt-maker" route?

I really like the way dropdown-list.el does selection (see
http://www.emacswiki.org/cgi-bin/wiki/dropdown-list.el, "overlays stolen
from company-mode.el").  It shows the list of choices inside the buffer
as a true popup.  To me that looks much better than y-or-n-p if the
terminal supports it.  If Emacs doesn't have anything similar, I think
it's a nice addition to the core UI functionality.  Let me know and I'll
propose it on emacs-devel if necessary.

Ted

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

[Stefan Monnier]

SM> And that leads to an absence of cursor in the minibuffer, even though
SM> it's fundamentally a prompt.  Why not copy y-or-n-p from subr.el as
SM> a starting point?
SM> If you can factor out the commonality, I'd be happy to provide
SM> a "prompt-maker" function and then define y-or-n-p in terms of that
SM> prompt-maker.

> Can I really be the only one to need this?  Weird.  I actually used
> `read-char-choice' first but XEmacs doesn't support it.  Perhaps Gnus
> should provide a compatibility wrapper that uses it opportunistically.
> Would you rather go the "prompt-maker" route?

Oh, I didn't even remember read-char-choice, but yes, that's probably
a better starting point.  We should actually make y-or-n-p use
read-char-choice.

> I really like the way dropdown-list.el does selection (see
> http://www.emacswiki.org/cgi-bin/wiki/dropdown-list.el, "overlays stolen
> from company-mode.el").  It shows the list of choices inside the buffer
> as a true popup.  To me that looks much better than y-or-n-p if the
> terminal supports it.  If Emacs doesn't have anything similar, I think
> it's a nice addition to the core UI functionality.  Let me know and I'll
> propose it on emacs-devel if necessary.

I don't know what that would look like in your y/n/N/e/? case.


        Stefan

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

[Ted Zlatanov]

(argh, accidentally posted this to just the Gnus bug tracker list,
resending to bug-gnu-emacs)

On Tue, 08 Mar 2011 22:04:17 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> Oh, I didn't even remember read-char-choice, but yes, that's probably
SM> a better starting point.  We should actually make y-or-n-p use
SM> read-char-choice.

I added `auth-source-read-char-choice' to do the prompting.  It will use
`read-char-choice' opportunistically and construct the a/b/c prompt
supplement automatically.  If you want me to modify `y-or-n-p' to use
`read-char-choice' let me know and I'll submit a patch.

>> I really like the way dropdown-list.el does selection (see
>> http://www.emacswiki.org/cgi-bin/wiki/dropdown-list.el, "overlays stolen
>> from company-mode.el").  It shows the list of choices inside the buffer
>> as a true popup.  To me that looks much better than y-or-n-p if the
>> terminal supports it.  If Emacs doesn't have anything similar, I think
>> it's a nice addition to the core UI functionality.  Let me know and I'll
>> propose it on emacs-devel if necessary.

SM> I don't know what that would look like in your y/n/N/e/? case.

Try (dropdown-list '("choose one: y" "............n" "............N"))
since that's how it will look with the new
`auth-source-char-read-choice' function.

I disabled `dropdown-list' in that function because it didn't work when
called from the :save-function lambda, although it worked interactively.
I think it needs to be outside the echo area but couldn't figure out how
to fix it.  Can I say "switch to any non-echo area window"?

Ted

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

[Stefan Monnier]

> I added `auth-source-read-char-choice' to do the prompting.  It will use
> `read-char-choice' opportunistically and construct the a/b/c prompt
> supplement automatically.

Good.

> If you want me to modify `y-or-n-p' to use `read-char-choice' let me
> know and I'll submit a patch.

That would be a good change, yes, please.

>>> I really like the way dropdown-list.el does selection (see
>>> http://www.emacswiki.org/cgi-bin/wiki/dropdown-list.el, "overlays stolen
>>> from company-mode.el").  It shows the list of choices inside the buffer
>>> as a true popup.  To me that looks much better than y-or-n-p if the
>>> terminal supports it.  If Emacs doesn't have anything similar, I think
>>> it's a nice addition to the core UI functionality.  Let me know and I'll
>>> propose it on emacs-devel if necessary.

SM> I don't know what that would look like in your y/n/N/e/? case.

> Try (dropdown-list '("choose one: y" "............n" "............N"))
> since that's how it will look with the new
> `auth-source-char-read-choice' function.

Hmm... I'm not sure it's an improvement over the simple
"y/n/N/e/?" prompt.  For completions and other cases where the total
text is too long to fit on a single line, such a dropdown-list can make
sense, but for this particular case it just reminds of me people using
tons of different typefaces in Word document.


        Stefan

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

[Ted Zlatanov]

On Wed, 09 Mar 2011 13:34:06 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 
SM> Ted wrote:
>> If you want me to modify `y-or-n-p' to use `read-char-choice' let me
>> know and I'll submit a patch.

SM> That would be a good change, yes, please.

I'll propose on emacs-devel.

>> Try (dropdown-list '("choose one: y" "............n" "............N"))
>> since that's how it will look with the new
>> `auth-source-char-read-choice' function.

SM> Hmm... I'm not sure it's an improvement over the simple
SM> "y/n/N/e/?" prompt.  For completions and other cases where the total
SM> text is too long to fit on a single line, such a dropdown-list can make
SM> sense, but for this particular case it just reminds of me people using
SM> tons of different typefaces in Word document.

OK, I've removed the dropdown-list stuff.  Can you close this bug or let
me know what else is needed?

Thanks
Ted

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

[Stefan Monnier]

> Can you close this bug or let me know what else is needed?

I'll close it as soon as I confirm the new behavior fixes the problems.


        Stefan

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

[Stefan Monnier]

>> Can you close this bug or let me know what else is needed?
> I'll close it as soon as I confirm the new behavior fixes the problems.

Here's the update:
- It's much better, almost right.
- The user prompt says "user blabla: monnier", rather than "user blabla
  (default monnier): ".  I.e. the `initial-content' should be empty, and
  the user name should be passed as `default' instead.
- The "save password" prompt shows up not only after I entered the
  password, but also when re-connecting (and using the password kept in
  memory).


        Stefan

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

[Ted Zlatanov]

On Fri, 11 Mar 2011 22:43:00 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>>> Can you close this bug or let me know what else is needed?
>> I'll close it as soon as I confirm the new behavior fixes the problems.

SM> Here's the update:
SM> - It's much better, almost right.
SM> - The user prompt says "user blabla: monnier", rather than "user blabla
SM>   (default monnier): ".  I.e. the `initial-content' should be empty, and
SM>   the user name should be passed as `default' instead.

Fixed.

SM> - The "save password" prompt shows up not only after I entered the
SM>   password, but also when re-connecting (and using the password kept in
SM>   memory).

This is fixed too.

Ted

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

[Stefan Monnier]

>>>> Can you close this bug or let me know what else is needed?
>>> I'll close it as soon as I confirm the new behavior fixes the problems.

SM> Here's the update:
SM> - It's much better, almost right.
SM> - The user prompt says "user blabla: monnier", rather than "user blabla
SM> (default monnier): ".  I.e. the `initial-content' should be empty, and
SM> the user name should be passed as `default' instead.

> Fixed.

SM> - The "save password" prompt shows up not only after I entered the
SM> password, but also when re-connecting (and using the password kept in
SM> memory).

> This is fixed too.

Thanks, looks fine now,


        Stefan