From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: how-many/count-matches for non-interactive use Date: Sat, 23 Oct 2004 15:36:29 -0500 (CDT) Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <200410232036.i9NKaTc05040@raven.dms.auburn.edu> References: <87pt3m5vqk.fsf@oak.pohoyda.family> <87zn2mh5jk.fsf-monnier+emacs@gnu.org> <87is99nznd.fsf-monnier+emacs@gnu.org> <200410172053.i9HKrdL01136@raven.dms.auburn.edu> <200410190158.i9J1wrH25523@raven.dms.auburn.edu> <200410200127.i9K1Rpp28384@raven.dms.auburn.edu> <200410210308.i9L38Dm10997@raven.dms.auburn.edu> <200410222222.i9MMMD515903@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1098563988 9970 80.91.229.6 (23 Oct 2004 20:39:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 23 Oct 2004 20:39:48 +0000 (UTC) Cc: jpw@gnu.org, klm@zope.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, storm@cua.dk, alexander.pohoyda@gmx.net Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 23 22:39:34 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CLSfj-0002Cm-00 for ; Sat, 23 Oct 2004 22:39:32 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CLSnI-0005lG-Ov for ged-emacs-devel@m.gmane.org; Sat, 23 Oct 2004 16:47:20 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CLSmc-0005Ni-KW for emacs-devel@gnu.org; Sat, 23 Oct 2004 16:46:39 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CLSmY-0005Lb-FA for emacs-devel@gnu.org; Sat, 23 Oct 2004 16:46:34 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CLSmY-0005LR-DN for emacs-devel@gnu.org; Sat, 23 Oct 2004 16:46:34 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CLSet-0003FY-C4; Sat, 23 Oct 2004 16:38:39 -0400 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id i9NKc0iU026715; Sat, 23 Oct 2004 15:38:00 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id i9NKaTc05040; Sat, 23 Oct 2004 15:36:29 -0500 (CDT) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Sat, 23 Oct 2004 14:49:03 -0400) 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: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:28806 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:28806 Richard Stallman wrote: It is not a no-op, but it is not correct either. These commands as currently written would behave incorrectly in some cases in a keyboard macro. I do not believe so (I checked). I still believe those lines are no-ops and should simply be deleted, like my patch does. (interactive "r\nNSet left margin to column: ") ! (setq width (prefix-numeric-value width)) That second line is redundant. The `N' code character already _gives_ the numeric value. Your approach to the first two is to delete the call to prefix-numeric-value. As far as I can see, that would extend the bug to the non-macro case. I do not believe so. I checked. The `N' already gives the numeric value. ! (setq inc (if inc (prefix-numeric-value current-prefix-arg) ! standard-indent)) That would appear wrong for non-interactive calls. For such calls `current-prefix-arg' would not give the prefix arg of `increase-right-margin', but of whichever function was actually called interactively (and then directly or indirectly called `increase-right-margin'). The line I used: ! (setq inc (if inc (prefix-numeric-value inc) standard-indent) is the _same_ line that is used in the three other completely analogous functions in indent.el. If there is something wrong with that line for `increase-right-margin', then there would be something wrong in the three other {in,de}crease-{left,right}-margin functions. I believe we need to use consistent code in all four. Anything else would appear to make no sense. I still believe my original patch is the logical solution in all three cases. >>From (elisp)Interactive Codes: `N' The numeric prefix argument; but if there is no prefix argument, read a number as with `n'. Requires a number. *Note Prefix Command Arguments::. Prompt. Note: The numeric prefix argument; Sincerely, Luc.