From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general,gmane.emacs.bugs Subject: Re: bug#8050: Gnus does not connect to my IMAP server any more Date: Thu, 24 Feb 2011 10:29:58 -0600 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87fwrd2y61.fsf@lifelogs.com> References: <87y655bnr4.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1298565054 31187 80.91.229.12 (24 Feb 2011 16:30:54 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 24 Feb 2011 16:30:54 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org To: ding@gnus.org Original-X-From: ding-owner+M25609@lists.math.uh.edu Thu Feb 24 17:30:50 2011 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Pse5X-0000sD-SN for ding-account@gmane.org; Thu, 24 Feb 2011 17:30:48 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1Pse57-0003yK-VL; Thu, 24 Feb 2011 10:30:22 -0600 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Pse55-0003y0-Ty for ding@lists.math.uh.edu; Thu, 24 Feb 2011 10:30:19 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1Pse54-0008Ab-Hj for ding@lists.math.uh.edu; Thu, 24 Feb 2011 10:30:19 -0600 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1Pse53-0006Lg-6R for ding@gnus.org; Thu, 24 Feb 2011 17:30:17 +0100 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Pse52-0000Z7-3P for ding@gnus.org; Thu, 24 Feb 2011 17:30:16 +0100 Original-Received: from 38.98.147.130 ([38.98.147.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Feb 2011 17:30:16 +0100 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Feb 2011 17:30:16 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 99 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.130 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6;d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110014 (No Gnus v0.14) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:J6yJZGUQ2EsJshzdYDb+KZPXCUM= X-Spam-Score: -0.7 (/) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:77282 gmane.emacs.bugs:44343 Archived-At: On Thu, 24 Feb 2011 10:22:55 -0500 Stefan Monnier 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