From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#17779: 24.4.50; (elisp) `Using Interactive' Date: Sat, 14 Jun 2014 08:50:37 -0700 (PDT) Message-ID: <79a25ee9-e53e-494f-b7e3-ebd2e2eebafa@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1402761158 12832 80.91.229.3 (14 Jun 2014 15:52:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Jun 2014 15:52:38 +0000 (UTC) To: 17779@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jun 14 17:52:28 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1WvqFm-0001VA-Fw for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Jun 2014 17:52:26 +0200 Original-Received: from localhost ([::1]:35766 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WvqFm-0001mz-6B for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Jun 2014 11:52:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45591) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WvqFY-0001mh-Vu for bug-gnu-emacs@gnu.org; Sat, 14 Jun 2014 11:52:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WvqFO-0007xV-KD for bug-gnu-emacs@gnu.org; Sat, 14 Jun 2014 11:52:12 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56728) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WvqFO-0007wz-HP for bug-gnu-emacs@gnu.org; Sat, 14 Jun 2014 11:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WvqFO-00045n-6Q for bug-gnu-emacs@gnu.org; Sat, 14 Jun 2014 11:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2014 15:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 17779 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.140276108015650 (code B ref -1); Sat, 14 Jun 2014 15:52:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 14 Jun 2014 15:51:20 +0000 Original-Received: from localhost ([127.0.0.1]:47878 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WvqEi-00044M-6j for submit@debbugs.gnu.org; Sat, 14 Jun 2014 11:51:20 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:43754) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WvqEe-000446-M0 for submit@debbugs.gnu.org; Sat, 14 Jun 2014 11:51:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WvqEP-0007i7-1t for submit@debbugs.gnu.org; Sat, 14 Jun 2014 11:51:11 -0400 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:47745) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WvqEO-0007i3-Uu for submit@debbugs.gnu.org; Sat, 14 Jun 2014 11:51:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45444) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WvqEG-0001B0-73 for bug-gnu-emacs@gnu.org; Sat, 14 Jun 2014 11:51:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WvqE3-0007eT-CG for bug-gnu-emacs@gnu.org; Sat, 14 Jun 2014 11:50:52 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:29696) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WvqE3-0007eP-5a for bug-gnu-emacs@gnu.org; Sat, 14 Jun 2014 11:50:39 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5EFobe6001089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 14 Jun 2014 15:50:37 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5EFoaPJ027036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 14 Jun 2014 15:50:36 GMT Original-Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5EFoa8W027033 for ; Sat, 14 Jun 2014 15:50:36 GMT X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:90380 Archived-At: I wonder about the bullet "It may be a Lisp expression that is not a string...". 1. The text for this does two things, which should perhaps be separated: (a) it describes the general nature and use of such an expression, and (b) it goes down a rabbit hole to talk about one particular gotcha. Combining these in the same bullet, which is supposed to present the non-st= ring Lisp sexp case, just confuses things - that's my guess. 2. Wrt that gotcha: Really? I'm probably missing something here, since this text has been in the manual for a long time. But here's my take on this gotcha. What am I missing? > Providing point or the mark as an argument value is also common, > but if you do this and read input (whether using the minibuffer > or not), be sure to get the integer values of point or the mark > after reading. Why? Why is after reading always (or typically) the appropriate time? > The current buffer may be receiving subprocess output; if > subprocess output arrives while the command is waiting for input, > it could relocate point and the mark. And? Why is the location after reading more appropriate than before? What does the input reading have to do, necessarily, with the timing of the external process and its possible effect on the buffer text? > Here's an example of what not to do: > (interactive > (list (region-beginning) (region-end) > (read-string "Foo: " nil 'my-history))) >=20 > Here's how to avoid the problem, by examining point and the mark > after reading the keyboard input: > (interactive > (let ((string (read-string "Foo: " nil 'my-history))) > (list (region-beginning) (region-end) string))) That does not make sense to me as a general guideline. The appropriate time for the interactive spec to record the region limits depends on just what behavior one wants for the particular command. I see no reason to assume that one always (or typically) wants the limits to be recorded after reading input instead of before. If text modifications because of some external process are a concern, then it is likely that the exact interaction between that process and user input action needs to be taken into account for the particular command definition. IOW, I don't see why such a generalization is appropriate here. What am I missing? [I would think it would be more typical (if any generalization is appropriate here) for the command to make sure that such a process finishes before checking the region limits, if the process can change them.] In GNU Emacs 24.4.50.1 (i686-pc-mingw32) of 2014-06-08 on ODIEONE Bzr revision: 117291 rgm@gnu.org-20140608234143-lxs3ijcc3exkcomq Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --prefix=3D/c/Devel/emacs/snapshot/trunk --enable-checking=3Dyes,glyphs 'CFLAGS=3D-O0 -g3' LDFLAGS=3D-Lc:/Devel/emacs/lib 'CPPFLAGS=3D-DGC_MCHECK=3D1 -Ic:/Devel/emacs/include''