From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#24353: 25.1.1: looking-back wrong info Date: Sat, 3 Sep 2016 11:10:38 -0700 (PDT) Message-ID: References: <83lgzael08.fsf@gnu.org> <83k2euehyc.fsf@gnu.org> <1a485a01-87cd-db03-4a0b-2e9033754c46@yandex.ru> <77b23825-05cb-1f30-ebee-4b70dbfa986c@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1472926281 4766 195.159.176.226 (3 Sep 2016 18:11:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 3 Sep 2016 18:11:21 +0000 (UTC) To: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel , 24353@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 03 20:11:17 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bgFPQ-0000fe-18 for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Sep 2016 20:11:16 +0200 Original-Received: from localhost ([::1]:47355 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgFPN-0000D7-Ey for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Sep 2016 14:11:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35039) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgFPG-0000Bl-IP for bug-gnu-emacs@gnu.org; Sat, 03 Sep 2016 14:11:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bgFPC-0004sc-CK for bug-gnu-emacs@gnu.org; Sat, 03 Sep 2016 14:11:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51205) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgFPC-0004sY-8y for bug-gnu-emacs@gnu.org; Sat, 03 Sep 2016 14:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bgFPB-0008Fl-Tq for bug-gnu-emacs@gnu.org; Sat, 03 Sep 2016 14:11:01 -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, 03 Sep 2016 18:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24353 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix notabug Original-Received: via spool by 24353-submit@debbugs.gnu.org id=B24353.147292625031708 (code B ref 24353); Sat, 03 Sep 2016 18:11:01 +0000 Original-Received: (at 24353) by debbugs.gnu.org; 3 Sep 2016 18:10:50 +0000 Original-Received: from localhost ([127.0.0.1]:48917 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bgFOz-0008FM-Ul for submit@debbugs.gnu.org; Sat, 03 Sep 2016 14:10:50 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:24506) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bgFOx-0008F7-Qb for 24353@debbugs.gnu.org; Sat, 03 Sep 2016 14:10:48 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u83IAfC0018116 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 3 Sep 2016 18:10:41 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id u83IAePg002081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 3 Sep 2016 18:10:40 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u83IAdXd027436; Sat, 3 Sep 2016 18:10:40 GMT In-Reply-To: <77b23825-05cb-1f30-ebee-4b70dbfa986c@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6753.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:122897 Archived-At: > >> > thus making their code likely faster. Users like faster programs. > > > > The right way to _encourage_ programmers to use it is to > > tell them precisely that: "Using LIMIT is recommended - it > > typically results in faster code." > > > > Or "strongly recommended". Or "You're nuts if you omit LIMIT!" > > Or whatever other positive or negative encouragement you think > > might be most effective and appropriate. > > > > Telling them nothing about this and, instead, just showing a > > false signature, does NOT help them. >=20 > This sounds wrong. The signature change causes warnings on > all uses that don't specify LIMIT. No, it does not. M-: (looking-back "a") returns t or nil. It does not raise an error. Likewise, if you evaluate that sexp in a buffer or *.el file. The _byte-compiler_ warning has already been mentioned. > That's how I learnt about the change; I wouldn't have > updated my code otherwise. It's not about _updating_ code. There is nothing new here. Not providing LIMIT has always been a bad idea because of performance. When you first wrote your code, presumably you consulted the doc string. The problem, if you did read the doc, is that the "general recommendation" there, at the very end, SAYS NOTHING about LIMIT. It simply recommends not to use `looking-back' at all, if you can avoid it. The right fix is to have the doc do three things: 1. Be honest about the signature. 2. Recommend strongly that you use LIMIT. 3. Say WHY you should use LIMIT: not doing so can lead to poor performance. Had #2 and #3 been in the doc when you (presumably) first consulted it, you would likely have included LIMIT, and there would be no need to "upgrade" your code now. Is there a reason to avoid using `looking-back', even if LIMIT is provided? It too should be mentioned in the doc. =20 > So changing the advertised signature seems to help, if > only due to the warning side-effect. Just fix the doc. It's not about "upgrading" anything. NOTHING HAS CHANGED in this function, apart from a minor doc change and addition of `advertised-calling-convention'.