From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/80429 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel,gmane.emacs.gnus.general Subject: RE: smtp crap Date: Wed, 26 Oct 2011 17:08:38 -0700 Message-ID: <9BE333E32E9C4B9B866D5FC6E4C41D38@us.oracle.com> References: <8739f4kzp3.fsf@catnip.gol.com><87ipo0p1bc.fsf@stupidchicken.com><58C87CB9F44943A7BBE78F2D6B62A850@us.oracle.com><5997613E240C402C877A76C688773E65@us.oracle.com> <4D117A6B-0C4E-4F13-AC0E-C64DAB66C996@mit.edu> <447111A2EC694399973999C249891686@us.oracle.com> <1C9CC457-A5D9-40F4-9D26-7A4C37829042@MIT.EDU> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1319674140 13749 80.91.229.12 (27 Oct 2011 00:09:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 27 Oct 2011 00:09:00 +0000 (UTC) Cc: ding@gnus.org, 'Emacs devel' To: "'chad'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 27 02:08:56 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 1RJDWh-0007Ks-2F for ged-emacs-devel@m.gmane.org; Thu, 27 Oct 2011 02:08:55 +0200 Original-Received: from localhost ([::1]:58494 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJDWf-00085F-Tt for ged-emacs-devel@m.gmane.org; Wed, 26 Oct 2011 20:08:53 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:45331) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJDWd-000856-9R for emacs-devel@gnu.org; Wed, 26 Oct 2011 20:08:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RJDWb-0004DF-Rs for emacs-devel@gnu.org; Wed, 26 Oct 2011 20:08:51 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:35134) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJDWb-0004D9-KS for emacs-devel@gnu.org; Wed, 26 Oct 2011 20:08:49 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9R08lvD015671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Oct 2011 00:08:48 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p9R08k6I007410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Oct 2011 00:08:47 GMT Original-Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p9R08en6025987; Wed, 26 Oct 2011 19:08:41 -0500 Original-Received: from dradamslap1 (/10.159.53.56) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 26 Oct 2011 17:08:40 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1C9CC457-A5D9-40F4-9D26-7A4C37829042@MIT.EDU> Thread-Index: AcyUNOurlfjejsXIQNWhVx29i55oYgAAk5FQ 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.4EA8A110.012B: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: 148.87.113.117 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:145609 gmane.emacs.gnus.general:80429 Archived-At: > pretty clearly answers the question ``Why burden and confuse > users now?''. No, it does not. It neither justifies the burden and confusion nor explains why _now_. If as you say the problem is real and not new, why now? Why didn't RMS et al tackle it many, many moon ago? Wasn't it important enough? Fewer mails sat idle in local queues back then? I foresee your answer: email is more complicated now. Tough. That's not a reason for Emacs to act idiotically. > > The solution is to simply _mention_ in the bug-report > > instructions that "IF you have no mail client and > > IF you have not yet configured Emacs itself as a mailer, > > THEN invoke `M-x XYZ' to so configure it.", where XYZ is a > > command that leads you down whatever configuration garden path > > is required. > > So, you want to ask the user, No. read what I said. I do _not_ want Emacs to ask the user anything here. That's the point, in fact. > in the middle of reporting a bug, to notice that there's a warning I did not mention "warning". The instructions and information we give to users preparing a bug report, including what I suggested, are not "warnings". > somewhere, and then guess whether or not emacs can send mail > without extra steps on their part, Absolutely not. Read what I wrote: "If _you_ have not yet configured...". There is nothing requiring the user to guess whether Emacs might be able to send mail. > when we know that a common failure mode is ``it doesn't work and > the user can't reasonably know that it didn't/won't work''. The user will reasonably know whether s?he has an email client (can send mail outside Emacs). The user will reasonably know whether s?he has already explicitly configured Emacs itself for email. There are of course always some users who fall outside of "reasonable". And yes, knowledgable user X might lend his machine and Emacs to ignorant user Y. Stuff happens. We have never even tried mentioning this to users. Who knows how many of the "reasonable" users you cite would still end up with local mail queues full of bug reports, if we simply informed them. We might also mention to them that they will receive a confirmation email, if sending their bug report is successful. How many unsuccessful bug reports do you think will fill up the local queues of "reasonable" users if we tell them to expect an ACK mail? Will users read all of this info each time they prepare a bug report? Of course not. But they will likely read it the first time. And there's no reason not to let them know these things. > Seems like a pretty poor default to me. YMMV. We've seen the solution you favor. Even a simple `mailto:' would, in most cases, cause a user with no SMTP configured and no other support for `mailto:' to see an error raised (e.g. by a browser). Why assume that Emacs must blindly remain silent over and over, simply filling up a local mail queue with bug reports? I'm no expert on email, but I know a lousy UI when I see one. If it weren't for my complaints and those by a few others (e.g. Miles), we would still have the bass ackwards dialog that Lars originally implemented to solve this problem. That solution drew no objection from the Emacs maintainers or other developers arguing your position. Just because you can recognize a problem does not mean that you have found a proper solution. Burdening and confusing _all_ users is not the right way to avoid having a few users think they sent email when they didn't. Try harder.