From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: Errors in interactive commands Date: Wed, 3 Aug 2011 11:37:38 +0200 Message-ID: References: <87livbbta9.fsf@gmail.com> <4E38E70B.7030802@online.de> <87aabrhs2o.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1312364292 29231 80.91.229.12 (3 Aug 2011 09:38:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 3 Aug 2011 09:38:12 +0000 (UTC) Cc: Antoine Levitt , =?UTF-8?Q?Andreas_R=C3=B6hler?= , Stefan Monnier , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 03 11:38:06 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 1QoXts-0004EG-PO for ged-emacs-devel@m.gmane.org; Wed, 03 Aug 2011 11:38:04 +0200 Original-Received: from localhost ([::1]:51508 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoXts-0007RN-5R for ged-emacs-devel@m.gmane.org; Wed, 03 Aug 2011 05:38:04 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:45944) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoXtp-0007Q4-3p for emacs-devel@gnu.org; Wed, 03 Aug 2011 05:38:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QoXtn-0007x0-Qm for emacs-devel@gnu.org; Wed, 03 Aug 2011 05:38:01 -0400 Original-Received: from mail-ew0-f41.google.com ([209.85.215.41]:49831) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoXtn-0007wc-MI for emacs-devel@gnu.org; Wed, 03 Aug 2011 05:37:59 -0400 Original-Received: by ewy9 with SMTP id 9so338892ewy.0 for ; Wed, 03 Aug 2011 02:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=gje2nVlBwqkiUpTvmtu1KRrQvYpbUQK4ih5rmuSqUSk=; b=L0vdE3XDyanCEVimMULTZVOHmLPpgTZO6YzC+R8vr2NQ40TpSF2SsN7dMGTRFXgyIb fRoIbLGVlUOXysO6L3ywepsXkgJAaLX4LTocY2w+pA3Ew4fsiaNll8wE6/QcJ/JKoucz WYhoWG1ZnNPwuLTTyuMRBbglaZzsiN5ROQWCw= Original-Received: by 10.213.22.68 with SMTP id m4mr2276723ebb.125.1312364278534; Wed, 03 Aug 2011 02:37:58 -0700 (PDT) Original-Received: by 10.213.12.205 with HTTP; Wed, 3 Aug 2011 02:37:38 -0700 (PDT) In-Reply-To: <87aabrhs2o.fsf@uwakimon.sk.tsukuba.ac.jp> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.215.41 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:142800 Archived-At: On Wed, Aug 3, 2011 at 09:28, Stephen J. Turnbull wrot= e: > Andreas R=C3=B6hler writes: > > =C2=A0> A move-forward at the end of the buffer isn't a wrong command as = such, > =C2=A0> just will not be successful. > =C2=A0> > =C2=A0> Therefor it should not be raised an error, just nil returned. > > This is problematic, IMO. =C2=A0Suppose you have a buffer which is suppos= ed > to have an even number of objects in it, and you want to delete every > second then. =C2=A0Then > > (progn > =C2=A0(goto (point-min)) > =C2=A0(while (not (eobp)) > =C2=A0 =C2=A0(forward-object 2) > =C2=A0 =C2=A0(delete-object -1))) > > DTRTs, including detecting the "incorrect state" of an odd number of > objects, and not deleting the first object on an incomplete last line. > > If you're going to change the behavior of the movement commands here, > I think it would be better to have them return the number of objects > left to move over. =C2=A0Then 0 would mean (complete) success (how Un*x-y= !) > > But this would be a major change. Examples such like this one is why I propose using something like (throw 'command-level) instead of raising an error. Of course the catch tag 'command-level does not exist and I propose adding it in the C code command loops in so that (throw 'command-level) gives an execution path similar to (error 'something). In this way I think we will get rather few compatibility problems. Maybe this can be introduced in debug-ignored-errors?