From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Errors in interactive commands Date: Thu, 04 Aug 2011 11:15:16 +0900 Message-ID: <87vcudhqh7.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87livbbta9.fsf@gmail.com> <4E38E70B.7030802@online.de> <87aabrhs2o.fsf@uwakimon.sk.tsukuba.ac.jp> <4E38FCC4.1030001@online.de> <8739hij1y3.fsf@uwakimon.sk.tsukuba.ac.jp> <4E392365.2080401@online.de> 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 1312424128 4816 80.91.229.12 (4 Aug 2011 02:15:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 4 Aug 2011 02:15:28 +0000 (UTC) Cc: Antoine Levitt , Lennart Borgman , Stefan Monnier , emacs-devel@gnu.org To: Andreas =?iso-8859-1?Q?R=F6hler?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 04 04:15:23 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 1QonSz-0008LU-T5 for ged-emacs-devel@m.gmane.org; Thu, 04 Aug 2011 04:15:22 +0200 Original-Received: from localhost ([::1]:55263 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QonSu-0001wI-3n for ged-emacs-devel@m.gmane.org; Wed, 03 Aug 2011 22:15:16 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:57023) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QonSr-0001wA-4I for emacs-devel@gnu.org; Wed, 03 Aug 2011 22:15:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QonSp-0005CX-I5 for emacs-devel@gnu.org; Wed, 03 Aug 2011 22:15:13 -0400 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:57256) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QonSp-0005C0-24 for emacs-devel@gnu.org; Wed, 03 Aug 2011 22:15:11 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 0A2373FA072D; Thu, 4 Aug 2011 11:15:08 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 651D71A26F8; Thu, 4 Aug 2011 11:15:16 +0900 (JST) In-Reply-To: <4E392365.2080401@online.de> X-Mailer: VM 8.1.93a under 21.5 (beta31) "ginger" cd1f8c4e81cd XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.223 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:142849 Archived-At: Andreas R=F6hler writes: > > and you need to define it and show that there is a unified > > definition powerful enough to make it worthwhile to introduce a > > backward-incompatible change. [...] > for example the implemented form forward-word already sends nil, > not error, when buffer-end is reached. Remains still to get it > messaged. >=20 > Thus implemented forward-word would allow a similar writing as > below. Sure. You said that already, you should assume we understand that. (Especially since XEmacs already specifies `forward-word' to fail with nil rather than an error at buffer boundaries, you should assume that I know that. Even though Emacs rarely worries more than a plugged nickel about XEmacs compatibility, I think in this case it's actually the strongest argument you have. Ie, the backward compatibility problem is probably hardly important. Search for `(featurep 'xemacs)' near `forward-word' to verify.) Now we have two use cases, one of which needs the error, and one of which prefers a null return. That fails the "unified" test (see my partial quote reproduced above). If you want to use this idiom, it is easy, though somewhat inefficent, to get your desired behavior via (defun my-forward-word (&optional COUNT BUFFER) "exercise for the the reader" (condition-case nil (forward-word) ((beginning-of-buffer end-of-buffer) nil) If you do this a lot, it's trivial to implement a macro. I really don't think it's worth your while to fight this. > (defun my-collects () > "Report and return all word boundaries in current buffer, a list. " > (interactive) > (goto-char (point-min)) > (let ((positions-reached nil) > (word-bounderies nil) > erg bnds) > (while (setq erg (ar-forward-word-atpt)) > (add-to-list 'positions-reached erg) > (setq bnds (ar-bounds-of-word-atpt)) > (add-to-list 'word-bounderies bnds)) > (when (interactive-p) (message "positions-reached: %s"=20 > positions-reached)) > (when (interactive-p) (message "word-bounderies: %s" word-bounderie= s)) > ;; positions-reached > word-bounderies > )) >=20 > Just try to write that with means commonly available. It's trivial, of course. For the single line containing "while", substitute (while (and (save-excursion (skip-syntax-forward "^w") (not (eobp))) (setq erg (ar-forward-word-atpt))) Of course it's prettier with `forward-word' specified your way, but similarly the case I have in mind where partial failure of multiple unit movement is an invalid state, not a termination condition, is prettier with the current definition.