From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel,gmane.emacs.gnus.general Subject: RE: smtp crap Date: Tue, 11 Oct 2011 09:24:02 -0700 Message-ID: <20FFD44DE7DF42C78FDDA3EF06397A78@us.oracle.com> References: <8739f4kzp3.fsf@catnip.gol.com><87ipo0p1bc.fsf@stupidchicken.com><58C87CB9F44943A7BBE78F2D6B62A850@us.oracle.com><83botsf06d.fsf@gnu.org><83k48cxj85.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1318350267 18873 80.91.229.12 (11 Oct 2011 16:24:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 11 Oct 2011 16:24:27 +0000 (UTC) Cc: cyd@stupidchicken.com, ding@gnus.org, emacs-devel@gnu.org, 'Stefan Monnier' , larsi@gnus.org, 'Eli Zaretskii' , miles@gnu.org To: "'PJ Weisberg'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 11 18:24:22 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RDf7u-000318-Bo for ged-emacs-devel@m.gmane.org; Tue, 11 Oct 2011 18:24:22 +0200 Original-Received: from localhost ([::1]:49543 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDf7t-00087N-SY for ged-emacs-devel@m.gmane.org; Tue, 11 Oct 2011 12:24:21 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:45599) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDf7q-00087D-EY for emacs-devel@gnu.org; Tue, 11 Oct 2011 12:24:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RDf7p-0000ac-DC for emacs-devel@gnu.org; Tue, 11 Oct 2011 12:24:18 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:57474) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RDf7m-0000a7-Mw; Tue, 11 Oct 2011 12:24:14 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9BGOABJ010367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Oct 2011 16:24:12 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p9BGO9U4014853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Oct 2011 16:24:10 GMT Original-Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p9BGO4ou017072; Tue, 11 Oct 2011 11:24:04 -0500 Original-Received: from dradamslap1 (/10.159.50.234) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 Oct 2011 09:24:04 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcyILvXDJQ4XGxDKRJqiD1WYSqJ48QAAMvyQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4E946DAD.005F:SCFMA922111,ss=1,re=-4.000,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 141.146.126.227 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:144898 gmane.emacs.gnus.general:80300 Archived-At: > > But MOST importantly, what about reporting bugs with `emacs -Q'? > > > > That is the real problem here, and the one that you keep=20 > > ignoring. =A0Instead, you keep focusing on the problem of > > customization, which is, relatively speaking, no big deal > > (assuming you finish fixing the repeated-interrogation bugs). >=20 > No, that's not the real problem. To me it is. It is a more important problem than how to help users = configure Emacs to use email. > There are two problems: > (1) What should Emacs do when the user asks it to send an email? > (2) What should Emacs do when the user asks it to report a bug? Agreed. > This series of questions is appropriate in scenario 1, but not in > scenario 2. I would say that _some email configuration UI_ is appropriate for #1, = but not for #2. But "some config UI" does not imply "this series of questions". I don't really care too much (personally) about what UI is used for #1. = But (FWIW) my advice would be for Emacs to (a) not _initiate_ that UI but = only provide it upon _user request_ and (b) probably not offer it as a = sequence of questions (e.g. wizard) at all, but rather as a form (e.g. checkboxes) = to fill in. Look at how other apps help users configure email, for some = inspiration... > (Especially with `emacs -Q', which causes an already-configured > Emacs to explicitly ignore its configuration.) Exactly. This is important. It should be the starting point. The fact that the UI interrogation-sequence-from-hell was (initially) = completely backward (see the bugs, some of which have been fixed), and that it is = still, well, weird, reflects the fact that this was NOT the starting point, = even though the configuration dialog is initiated by the `report-emacs-bug' code. > The fact that the two scenarios are related is an implementation > detail of report-emacs-bug. It might be currently, but it should not be. > The argument Drew is making would disappear instantly if > report-emacs-bug sent an HTTP POST request, for instance. Yes. But in that case Drew would argue that we should still also let = users report bugs using email. On this I support Richard's stance: users = should be able to report bugs using email. AND they should be able to do so using = HTTP. We should make it as easy as possible for a user to report an Emacs bug, especially using `emacs -Q'. That should be the priority - the rest is secondary, IMHO. And yes, this _should_ be a no-brainer.