From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 14 11:51:20 2014 Received: (at submit) by debbugs.gnu.org; 14 Jun 2014 15:51:20 +0000 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 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 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 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 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 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 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 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 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 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 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 MIME-Version: 1.0 Message-ID: <79a25ee9-e53e-494f-b7e3-ebd2e2eebafa@default> Date: Sat, 14 Jun 2014 08:50:37 -0700 (PDT) From: Drew Adams To: bug-gnu-emacs@gnu.org Subject: 24.4.50; (elisp) `Using Interactive' X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.5000 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) 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'' From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 04 09:14:34 2019 Received: (at 17779) by debbugs.gnu.org; 4 Aug 2019 13:14:34 +0000 Received: from localhost ([127.0.0.1]:60800 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1huGLK-0000Ji-Be for submit@debbugs.gnu.org; Sun, 04 Aug 2019 09:14:34 -0400 Received: from quimby.gnus.org ([80.91.231.51]:37358) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1huGLI-0000Hz-Ir for 17779@debbugs.gnu.org; Sun, 04 Aug 2019 09:14:32 -0400 Received: from 77.18.62.220.tmi.telenormobil.no ([77.18.62.220] helo=sandy) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1huFpj-0007OF-VD; Sun, 04 Aug 2019 14:41:58 +0200 From: Lars Ingebrigtsen To: Drew Adams Subject: Re: bug#17779: 24.4.50; (elisp) `Using Interactive' References: <79a25ee9-e53e-494f-b7e3-ebd2e2eebafa@default> Date: Sun, 04 Aug 2019 14:41:55 +0200 In-Reply-To: <79a25ee9-e53e-494f-b7e3-ebd2e2eebafa@default> (Drew Adams's message of "Sat, 14 Jun 2014 08:50:37 -0700 (PDT)") Message-ID: <87o9159k6k.fsf@mouse.gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Drew Adams writes: > 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 [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 TVD_RCVD_IP Message was received from an IP address -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 17779 Cc: 17779@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Drew Adams writes: > 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-string 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? (I've included the .texi below for reference.) Yes, I think you're right -- the text starting with "Providing point or the mark" until the end of the example seems like very confusing text to include in an introduction to `interactive'. The failure modes (if you can call it that) are hyper-specific to a very obscure case, and (as Drew says) what the user should do here depends on what the user wants. So I think that bit should just be removed from the manual. Any objections? ---- @item It may be a Lisp expression that is not a string; then it should be a form that is evaluated to get a list of arguments to pass to the command. Usually this form will call various functions to read input from the user, most often through the minibuffer (@pxref{Minibuffers}) or directly from the keyboard (@pxref{Reading Input}). Providing point or the mark as an argument value is also common, but if you do this @emph{and} read input (whether using the minibuffer or not), be sure to get the integer values of point or the mark after reading. 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. Here's an example of what @emph{not} to do: @smallexample (interactive (list (region-beginning) (region-end) (read-string "Foo: " nil 'my-history))) @end smallexample @noindent Here's how to avoid the problem, by examining point and the mark after reading the keyboard input: @smallexample (interactive (let ((string (read-string "Foo: " nil 'my-history))) (list (region-beginning) (region-end) string))) @end smallexample ---- -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 04 13:13:52 2019 Received: (at 17779) by debbugs.gnu.org; 4 Aug 2019 17:13:52 +0000 Received: from localhost ([127.0.0.1]:34189 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1huK4t-00008A-QD for submit@debbugs.gnu.org; Sun, 04 Aug 2019 13:13:52 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47513) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1huK4s-00007x-Iz for 17779@debbugs.gnu.org; Sun, 04 Aug 2019 13:13:51 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47796) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1huK4n-0004oY-3D; Sun, 04 Aug 2019 13:13:45 -0400 Received: from [176.228.60.248] (port=2829 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1huK4m-0002yf-JV; Sun, 04 Aug 2019 13:13:44 -0400 Date: Sun, 04 Aug 2019 20:13:28 +0300 Message-Id: <83r260dfbb.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-reply-to: <87o9159k6k.fsf@mouse.gnus.org> (message from Lars Ingebrigtsen on Sun, 04 Aug 2019 14:41:55 +0200) Subject: Re: bug#17779: 24.4.50; (elisp) `Using Interactive' References: <79a25ee9-e53e-494f-b7e3-ebd2e2eebafa@default> <87o9159k6k.fsf@mouse.gnus.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 17779 Cc: 17779@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Date: Sun, 04 Aug 2019 14:41:55 +0200 > Cc: 17779@debbugs.gnu.org > > Yes, I think you're right -- the text starting with "Providing point or > the mark" until the end of the example seems like very confusing text to > include in an introduction to `interactive'. It isn't an introduction, it's a full description of how to use 'interactive'. And I find nothing confusing about that part of the text, I think that single paragraph with 2 examples to illustrate the issue is quite appropriate here. Please just leave this alone. I object in principle to making significant changes in the manuals based on hair-splitting arguments, not in the least because someone will always come back later and claim that the new text is worse, or less clear, or whatever. At least in the docs, let's please avoid making changes for reasons that are so minuscule that they need a magnifying glass to see. We should not waste our energy making "limit-cycle" kind of changes. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 04 22:07:39 2019 Received: (at 17779) by debbugs.gnu.org; 5 Aug 2019 02:07:39 +0000 Received: from localhost ([127.0.0.1]:34418 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1huSPS-0001Bm-MX for submit@debbugs.gnu.org; Sun, 04 Aug 2019 22:07:38 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:48932) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1huSPQ-0001BO-D4 for 17779@debbugs.gnu.org; Sun, 04 Aug 2019 22:07:37 -0400 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x75243O9163172; Mon, 5 Aug 2019 02:07:30 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=GqHg9agfaIlqbAxzNhdTEpm7zCApxP0SYa2Iip8fvYo=; b=qV7lFBfKjZ37oY46RVHx1Z+6DrmR+dkkoNvGCzjYDizv2jih63Te3AsLIkPaDtf18IdS 33wlLnxI2VBUTBu5Ng/waCp2+t+0e+LIqLrI1fsNrvWEO4kI1XsT+qGXsN/ZDKRD1I9F oOx0ZBVBe9+rGwr1a4Hp28+Ahod0OlQqwX2h+47pjVuh9GjfgIydZgC9ZC6py3mzcwwt 11EiWwjM1dj/H1+xyTGNvsaXhD7Fx0knLzv59b/k1Fnajj/hdWzd1huxc7zN7oWUxGgp AHqKSkhs6bwU0kEBUcgXsfVlfZ7A4DsvNP/Dzw5rYbSqTDhXCKo4akuFUf57n4R0RdoR eA== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2120.oracle.com with ESMTP id 2u527pcdff-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 05 Aug 2019 02:07:30 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x7522Z7q061849; Mon, 5 Aug 2019 02:05:30 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3020.oracle.com with ESMTP id 2u5232td7t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 05 Aug 2019 02:05:29 +0000 Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x7525TUF025502; Mon, 5 Aug 2019 02:05:29 GMT MIME-Version: 1.0 Message-ID: <7b436413-02f5-4516-87b4-04e2aba06124@default> Date: Sun, 4 Aug 2019 19:05:28 -0700 (PDT) From: Drew Adams To: Lars Ingebrigtsen Subject: RE: bug#17779: 24.4.50; (elisp) `Using Interactive' References: <79a25ee9-e53e-494f-b7e3-ebd2e2eebafa@default> <87o9159k6k.fsf@mouse.gnus.org> In-Reply-To: <87o9159k6k.fsf@mouse.gnus.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4873.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9339 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=816 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908050019 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9339 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=866 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908050019 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 17779 Cc: 17779@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) I don't even think it should say: "Usually this form will call various functions to read input from the user, most often through the minibuffer (*note Minibuffers::) or directly from the keyboard (*note Reading Input::)." It can say that the form can read input etc. - that's fine. But I don't see the point of saying "usually". The point is that IF some argument needs to be obtained by getting user input then it that CAN be done by the form, e.g. reading from the minibuffer etc. But that's a nit. ("Often" is better than "usually", if you really want to stress that this is done often.) > Yes, I think you're right -- the text starting with "Providing point or > the mark" until the end of the example seems like very confusing text > to > include in an introduction to `interactive'. The failure modes (if you > can call it that) are hyper-specific to a very obscure case, and (as > Drew says) what the user should do here depends on what the user wants. >=20 > So I think that bit should just be removed from the manual. >=20 > Any objections? No objection from me, at least. Thanks for working on this. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 05 05:29:33 2019 Received: (at 17779) by debbugs.gnu.org; 5 Aug 2019 09:29:33 +0000 Received: from localhost ([127.0.0.1]:34623 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1huZJ7-00064h-Gv for submit@debbugs.gnu.org; Mon, 05 Aug 2019 05:29:33 -0400 Received: from quimby.gnus.org ([80.91.231.51]:52702) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1huZJ6-00064Y-9I for 17779@debbugs.gnu.org; Mon, 05 Aug 2019 05:29:32 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=sandy) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1huZJ1-0000zd-R2; Mon, 05 Aug 2019 11:29:30 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#17779: 24.4.50; (elisp) `Using Interactive' References: <79a25ee9-e53e-494f-b7e3-ebd2e2eebafa@default> <87o9159k6k.fsf@mouse.gnus.org> <83r260dfbb.fsf@gnu.org> Date: Mon, 05 Aug 2019 11:29:27 +0200 In-Reply-To: <83r260dfbb.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 04 Aug 2019 20:13:28 +0300") Message-ID: <87blx4dkp4.fsf@mouse.gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > It isn't an introduction, it's a full description of how to use > 'interactive'. And I find nothing confusing about that part of the > text, I think that single paragraph with 2 examples to illustra [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 17779 Cc: 17779@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > It isn't an introduction, it's a full description of how to use > 'interactive'. And I find nothing confusing about that part of the > text, I think that single paragraph with 2 examples to illustrate the > issue is quite appropriate here. I hadn't read that section before, and I just found it an odd thing to talk about in that context -- as if there was something in particular about code in the interactive spec that has to be extra careful about buffer contents changing, when that's a general issue with points. > Please just leave this alone. I object in principle to making > significant changes in the manuals based on hair-splitting arguments, > not in the least because someone will always come back later and claim > that the new text is worse, or less clear, or whatever. Emacs has great documentation, but it (as everything else) can be improved. The argument you're making here seems to veer into the "well, everything is subjective, so let's not even try" territory, which I know you don't mean. While going through these doc clarification bug reports, I do close the ones I don't think are not worth doing and only bring up the ones I think could benefit from some consideration. But you think the text here is fine, so I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 05 05:29:42 2019 Received: (at control) by debbugs.gnu.org; 5 Aug 2019 09:29:42 +0000 Received: from localhost ([127.0.0.1]:34626 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1huZJF-00065B-Pl for submit@debbugs.gnu.org; Mon, 05 Aug 2019 05:29:41 -0400 Received: from quimby.gnus.org ([80.91.231.51]:52718) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1huZJE-000653-39 for control@debbugs.gnu.org; Mon, 05 Aug 2019 05:29:40 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=sandy) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1huZJB-0000zk-Gm for control@debbugs.gnu.org; Mon, 05 Aug 2019 11:29:39 +0200 Date: Mon, 05 Aug 2019 11:29:37 +0200 Message-Id: <87a7codkou.fsf@mouse.gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #17779 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 17779 wontfix close 17779 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tags 17779 wontfix close 17779 quit From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 05 12:26:21 2019 Received: (at 17779) by debbugs.gnu.org; 5 Aug 2019 16:26:21 +0000 Received: from localhost ([127.0.0.1]:35758 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hufoS-00087z-W2 for submit@debbugs.gnu.org; Mon, 05 Aug 2019 12:26:21 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51387) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hufoR-00087l-6w for 17779@debbugs.gnu.org; Mon, 05 Aug 2019 12:26:19 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36007) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hufoL-0000io-Rb; Mon, 05 Aug 2019 12:26:13 -0400 Received: from [176.228.60.248] (port=4345 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hufoK-0002im-VJ; Mon, 05 Aug 2019 12:26:13 -0400 Date: Mon, 05 Aug 2019 19:25:59 +0300 Message-Id: <83ftmfd1ew.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-reply-to: <87blx4dkp4.fsf@mouse.gnus.org> (message from Lars Ingebrigtsen on Mon, 05 Aug 2019 11:29:27 +0200) Subject: Re: bug#17779: 24.4.50; (elisp) `Using Interactive' References: <79a25ee9-e53e-494f-b7e3-ebd2e2eebafa@default> <87o9159k6k.fsf@mouse.gnus.org> <83r260dfbb.fsf@gnu.org> <87blx4dkp4.fsf@mouse.gnus.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 17779 Cc: 17779@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: drew.adams@oracle.com, 17779@debbugs.gnu.org > Date: Mon, 05 Aug 2019 11:29:27 +0200 > > Eli Zaretskii writes: > > > It isn't an introduction, it's a full description of how to use > > 'interactive'. And I find nothing confusing about that part of the > > text, I think that single paragraph with 2 examples to illustrate the > > issue is quite appropriate here. > > I hadn't read that section before, and I just found it an odd thing to > talk about in that context -- as if there was something in particular > about code in the interactive spec that has to be extra careful about > buffer contents changing, when that's a general issue with points. Right, and that is exactly the point what the text tries to make. > > Please just leave this alone. I object in principle to making > > significant changes in the manuals based on hair-splitting arguments, > > not in the least because someone will always come back later and claim > > that the new text is worse, or less clear, or whatever. > > Emacs has great documentation, but it (as everything else) can be > improved. The argument you're making here seems to veer into the "well, > everything is subjective, so let's not even try" territory, which I know > you don't mean. Indeed I didn't mean anything even close, and I'm sorry it seemed to come across as something very different from my intent. I specifically mentioned "hair-splitting" and "minuscule" to make my intent clear, but I guess this wasn't enough. Our documentation does have places which need improvement -- places where the text is unclear or confusing or presents the subject in an order that is methodologically wrong, etc. This particular text is none of the above: it is very clear, describes real practical issues, presents them in an order which makes sense, and is quite short, even with the 2 examples and the surrounding small digression. So my point is that this is not one of the places where the manuals really do need improvement, it's a place where different people might have different opinions due to their personal preferences and experience. > While going through these doc clarification bug reports, I do close > the ones I don't think are not worth doing and only bring up the > ones I think could benefit from some consideration. I very much respect your opinions on those matters, and this case is a very rare situation where we happen to disagree. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 05 23:20:16 2019 Received: (at 17779) by debbugs.gnu.org; 6 Aug 2019 03:20:16 +0000 Received: from localhost ([127.0.0.1]:36120 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1huq1I-0007ic-3R for submit@debbugs.gnu.org; Mon, 05 Aug 2019 23:20:16 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45790) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1huq1E-0007iL-I5 for 17779@debbugs.gnu.org; Mon, 05 Aug 2019 23:20:12 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44515) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1huq19-0008BH-7n; Mon, 05 Aug 2019 23:20:07 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1huq18-0002UR-C5; Mon, 05 Aug 2019 23:20:06 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman To: Drew Adams In-Reply-To: <7b436413-02f5-4516-87b4-04e2aba06124@default> (message from Drew Adams on Sun, 4 Aug 2019 19:05:28 -0700 (PDT)) Subject: Re: bug#17779: 24.4.50; (elisp) `Using Interactive' References: <79a25ee9-e53e-494f-b7e3-ebd2e2eebafa@default> <87o9159k6k.fsf@mouse.gnus.org> <7b436413-02f5-4516-87b4-04e2aba06124@default> Message-Id: Date: Mon, 05 Aug 2019 23:20:06 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 17779 Cc: larsi@gnus.org, 17779@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > It can say that the form can read input etc. - > that's fine. But I don't see the point of saying > "usually". The point is to help the user understand the usage this feature is intended for. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From unknown Tue Aug 19 01:58:39 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 03 Sep 2019 11:24:07 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator