From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: [patch] minor patch for register.el Date: Wed, 20 Feb 2013 07:27:18 -0800 Message-ID: <4279D539FD71421584E199995F074E83@us.oracle.com> References: <20130220.111807.1912441579815160723.yamato@redhat.com><55DAF5C025494EE6A6552D8E63E9AEF9@us.oracle.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1361374069 21864 80.91.229.3 (20 Feb 2013 15:27:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Feb 2013 15:27:49 +0000 (UTC) Cc: 'Masatake YAMATO' , emacs-devel@gnu.org To: "'John Yates'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 20 16:28:09 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U8BaZ-0000LE-7W for ged-emacs-devel@m.gmane.org; Wed, 20 Feb 2013 16:28:07 +0100 Original-Received: from localhost ([::1]:33447 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8BaE-0002nj-VT for ged-emacs-devel@m.gmane.org; Wed, 20 Feb 2013 10:27:46 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:50087) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8Ba2-0002l5-MW for emacs-devel@gnu.org; Wed, 20 Feb 2013 10:27:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U8BZz-0008Bz-EV for emacs-devel@gnu.org; Wed, 20 Feb 2013 10:27:34 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:32973) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8BZz-0008Bj-8D for emacs-devel@gnu.org; Wed, 20 Feb 2013 10:27:31 -0500 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1KFRQA7026192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Feb 2013 15:27:29 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1KFRQ4h010289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2013 15:27:26 GMT Original-Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1KFRPe1016760; Wed, 20 Feb 2013 09:27:25 -0600 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 20 Feb 2013 07:27:25 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac4PeVFQgE1muHlLScaEwqjF/Xo2MwABO6FQ X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 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:157211 Archived-At: > > Personally, I don't really care one way or the other - (a) > > show a message and do nothing or (b) raise an error. > > Raising an error would be tantamount to suggesting that it is user's > responsibility to _know_ a priori that the set is empty and to avoid > invoking the function. Encountering a normal boundary state is not an > error. > > I run with debug-on-error set. Raising errors for non-error > conditions is very distracting. Again, I don't care which we do here: message or error. But if you are worried about an error then you'd better look throughout register.el at the other commands. They pretty much all already raise errors for similar situations - see the cl assertions. Feel free to change the error raising in the patch to `message' calls, as far as I am concerned. Or use `user-error', as Christopher suggests. The point, for me, is not to open an empty window/frame here: display a message instead.