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:57:01 -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> <87twdwal8a.fsf@users.sourceforge.net> 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 1472929105 22681 195.159.176.226 (3 Sep 2016 18:58:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 3 Sep 2016 18:58:25 +0000 (UTC) Cc: 24353@debbugs.gnu.org, =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel To: npostavs@users.sourceforge.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 03 20:58:18 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 1bgG8s-0004oK-PR for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Sep 2016 20:58:15 +0200 Original-Received: from localhost ([::1]:47460 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgG8q-0002I1-Jc for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Sep 2016 14:58:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41184) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgG8k-0002Ff-Hx for bug-gnu-emacs@gnu.org; Sat, 03 Sep 2016 14:58:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bgG8g-0004Ko-GX for bug-gnu-emacs@gnu.org; Sat, 03 Sep 2016 14:58:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51253) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgG8g-0004Kf-DY for bug-gnu-emacs@gnu.org; Sat, 03 Sep 2016 14:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bgG8g-0000yq-3Y for bug-gnu-emacs@gnu.org; Sat, 03 Sep 2016 14:58: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, 03 Sep 2016 18:58:02 +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.14729290333706 (code B ref 24353); Sat, 03 Sep 2016 18:58:02 +0000 Original-Received: (at 24353) by debbugs.gnu.org; 3 Sep 2016 18:57:13 +0000 Original-Received: from localhost ([127.0.0.1]:48965 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bgG7s-0000xi-SF for submit@debbugs.gnu.org; Sat, 03 Sep 2016 14:57:13 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:28988) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bgG7q-0000xU-RA for 24353@debbugs.gnu.org; Sat, 03 Sep 2016 14:57:11 -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 u83Iv34G012036 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 3 Sep 2016 18:57:04 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 u83Iv3sY021879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 3 Sep 2016 18:57:03 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 u83Iv2Jl008681; Sat, 3 Sep 2016 18:57:03 GMT In-Reply-To: <87twdwal8a.fsf@users.sourceforge.net> 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:122907 Archived-At: > > The right fix is to have the doc do three things: > > > > 1. Be honest about the signature. >=20 > Casting this as a moral issue (about "honesty") doesn't seem to be > constructive. Anyway, the whole point of advertised-calling-convention > is to advertise a signature different from the actual implemented one. It's not about morality. It's about the signature being=20 accurate/truthful/correct. Substitute "accurate" if that makes it clearer. It's not a moral question. It's about helping users as best we can. What's the most helpful thing to do here? That's the question. And yes, "the whole point of advertised-calling-convention is to advertise a signature different from the actual implemented one." The question is whether that is the right thing to do _here_. It is a tool used sparingly. As I said at the outset, "I have a question as to why this was changed." I question whether _this_ change is a good one - whether this is a good case for using `advertised-calling-convention'. > > 2. Recommend strongly that you use LIMIT. > > 3. Say WHY you should use LIMIT: not doing so can lead > > to poor performance. >=20 > The doc string already says > LIMIT if non-nil speeds up the search by specifying a minimum > starting position, to avoid checking matches that would start > before LIMIT. Right. And is that not enough? Emacs itself uses `looking-back' without LIMIT in several places. Presumably those are places where it should NOT (or cannot) be used (or else they should be corrected). Why would we assume now that other programmers use `looking-back' without LIMIT when they should be providing LIMIT? IOW, where's the problem? > > 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 > The docstring already says > As a general recommendation, try to avoid using > =E2=80=98looking-back=E2=80=99 wherever possible, since it is slow. I know. That's why I asked the question. It just says that it is slow, without reference to LIMIT. Doesn't seem to be as helpful as it presumably could be. But again, are we sure that programmers are misusing the function? Or is this perhaps another case of if-it-aint-broke-dont-fix-it?