From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: y-or-n-p and emacs --daemon Date: Wed, 3 Dec 2008 13:53:06 -0800 (PST) Message-ID: <200812032153.mB3Lr6lH028972@mothra.ics.uci.edu> References: <18742.25383.80136.946560@a1i15.kph.uni-mainz.de> <87ocztcy3t.fsf@grumblesmurf.org> <87abbdm4t8.fsf@cyd.mit.edu> <200812031953.mB3Jr4qh027604@mothra.ics.uci.edu> <874p1lj7bp.fsf@cyd.mit.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1228341209 12758 80.91.229.12 (3 Dec 2008 21:53:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Dec 2008 21:53:29 +0000 (UTC) Cc: emacs-devel@gnu.org, Espen Wiborg To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 03 22:54:32 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1L7zfz-00074a-O0 for ged-emacs-devel@m.gmane.org; Wed, 03 Dec 2008 22:54:31 +0100 Original-Received: from localhost ([127.0.0.1]:56995 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L7zep-0006b3-68 for ged-emacs-devel@m.gmane.org; Wed, 03 Dec 2008 16:53:19 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L7zel-0006Zi-Fs for emacs-devel@gnu.org; Wed, 03 Dec 2008 16:53:15 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L7zek-0006ZC-US for emacs-devel@gnu.org; Wed, 03 Dec 2008 16:53:15 -0500 Original-Received: from [199.232.76.173] (port=51765 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L7zek-0006Yz-Ob for emacs-devel@gnu.org; Wed, 03 Dec 2008 16:53:14 -0500 Original-Received: from sallyv2.ics.uci.edu ([128.195.1.120]:55121) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1L7zek-0004Hj-7u for emacs-devel@gnu.org; Wed, 03 Dec 2008 16:53:14 -0500 Original-Received: from mothra.ics.uci.edu (mothra.ics.uci.edu [128.195.6.93]) by sallyv2.ics.uci.edu (8.13.7+Sun/8.13.7) with ESMTP id mB3Lr7Ye002946; Wed, 3 Dec 2008 13:53:07 -0800 (PST) Original-Received: (from dann@localhost) by mothra.ics.uci.edu (8.13.8+Sun/8.13.6/Submit) id mB3Lr6lH028972; Wed, 3 Dec 2008 13:53:06 -0800 (PST) In-Reply-To: <874p1lj7bp.fsf@cyd.mit.edu> (Chong Yidong's message of "Wed, 03 Dec 2008 16:07:54 -0500") Original-Lines: 27 X-ICS-MailScanner-Information: Please contact the ISP for more information X-ICS-MailScanner-ID: mB3Lr7Ye002946 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-ICS-MailScanner-From: dann@mothra.ics.uci.edu X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:106540 Archived-At: Chong Yidong writes: > Dan Nicolaescu writes: > > > > The only thing I can think of is to make y-or-n-p and yes-or-no-p > > > default to "no" when only the daemon's dummy terminal is open. > > > > Bad idea: > > (unless (y-or-n-p "Stop me from removing all your files") > > /bin/rm -rf / > > ) > > > > > Does anyone have a better suggestion? > > > > Ignore it, or fix it properly: so that it works like y-or-n-p when > > using -batch. > > I don't think that would solve the problem either, since AFAIU the > daemon might not have a user accessible terminal at all (as bug#1310). Bug#1310 is a long standing Gtk+ bug, Jan has made workarounds for it a few times, and it is looking at this instance too. So that bug is not related to this issue. BTW, the patch in #1310 is probably correct. > What we could do is to make y-or-n-p signal an error. IMO redefining the meaning of y-or-n-p is still not a good idea.