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#24969: 26.0.50; number-at-point Date: Mon, 21 Nov 2016 15:07:33 -0800 (PST) Message-ID: <30945b58-5353-4475-92b3-7e276f20750e@default> References: <87fumm9uti.fsf@gmx.net> <2b644637-6ade-b00f-aa35-07c390fc92c7@easy-emacs.de> <87twb2jkzs.fsf@users.sourceforge.net> <87polp7ze2.fsf@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 1479769698 8222 195.159.176.226 (21 Nov 2016 23:08:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 21 Nov 2016 23:08:18 +0000 (UTC) Cc: Stephen Berman , 24969@debbugs.gnu.org, npostavs@users.sourceforge.net To: Tino Calancha Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 22 00:08:14 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 1c8xh4-0000jT-Oc for geb-bug-gnu-emacs@m.gmane.org; Tue, 22 Nov 2016 00:08:10 +0100 Original-Received: from localhost ([::1]:52175 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c8xh5-00072n-4S for geb-bug-gnu-emacs@m.gmane.org; Mon, 21 Nov 2016 18:08:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32964) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c8xgz-00072a-PZ for bug-gnu-emacs@gnu.org; Mon, 21 Nov 2016 18:08:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c8xgw-0006Cg-Jz for bug-gnu-emacs@gnu.org; Mon, 21 Nov 2016 18:08:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50381) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c8xgw-0006CY-Fv for bug-gnu-emacs@gnu.org; Mon, 21 Nov 2016 18:08:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c8xgw-0000ts-3Z for bug-gnu-emacs@gnu.org; Mon, 21 Nov 2016 18:08:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Nov 2016 23:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24969 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: unreproducible Original-Received: via spool by 24969-submit@debbugs.gnu.org id=B24969.14797696653428 (code B ref 24969); Mon, 21 Nov 2016 23:08:02 +0000 Original-Received: (at 24969) by debbugs.gnu.org; 21 Nov 2016 23:07:45 +0000 Original-Received: from localhost ([127.0.0.1]:37546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c8xgf-0000tE-2J for submit@debbugs.gnu.org; Mon, 21 Nov 2016 18:07:45 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:16929) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c8xgd-0000t1-Fh for 24969@debbugs.gnu.org; Mon, 21 Nov 2016 18:07:43 -0500 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uALN7amb012301 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 21 Nov 2016 23:07:37 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id uALN7aYW022510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 21 Nov 2016 23:07:36 GMT Original-Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id uALN7YOf007980; Mon, 21 Nov 2016 23:07:34 GMT In-Reply-To: <87polp7ze2.fsf@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6753.5000 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] 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:125968 Archived-At: > > In Emacs 25.1 (emacs -Q), `number-at-point' at either > > the `-' or the `1' returns nil, for me. And I do not > > see why it should return a number. > > > > `number-at-point' is defined using `form-at-point' with > > THING `sexp' and predicate `numberp'. The sexp picked > > up at point is `foo-1', and that fails `numberp'. > > From the time when i opened Bug#24605, the > implementation, in master branch, of `number-at-point' > was different: it changed in commit 786ab4a5 (Bug#8634). > My patch was driven by this implementation. I didn't notice > that `number-at-point' behaves different in emacs-25. It behaves the same in Emacs 25.1 as previously. If something broke this after Emacs 25.1 then it should be reverted. > > What am I missing? Why should this rightfully return > > a number? I'm guessing that you are all using a more > > recent version of `number-at-point' than what is in > > Emacs 25.1 (?). But to me the Emacs 25.1 behavior I > > see (i.e., returning nil) is correct. > > > > Did someone change the meaning of `number-at-point' > > so that it now picks up a numeral that is not isolated? > > If so, why would that be considered proper behavior? > > At the very least it is not backward-compatible behavior. > > That's right. Commit above breaks backward-compatibility. If it returns a number for point on a numeral in the middle of a symbol name etc. then it breaks not only backward compatibility - it breaks the very notion of a number at point. A number at point should be a number as delimited and distinguished in the current mode. The longstanding definition uses Lisp `read', so it distinguishes a _Lisp_ number. It uses what Lisp uses to delimit a numeral. A better implementation of `number-at-point' than what has always existed would do this: 1. Get (thing-at-point 'sexp) 2. If it is not a string, return nil. 3. Else match it against a regexp that tests for a numeral in the current mode/context. Or use another such test other than regexp matching. If there the mode/context defines numeric syntax then perhaps use a function that tests that way. 4. For Lisp, the result must coincide with the longstanding behavior, one way or another. Unless `number-at-point' is extended in such a way, it should simply be restored to what it has always been. It's behavior in Lisp should in any case be to return a Lisp number. I think that its behavior should remain what it was (a Lisp number), and any more general function that does as just described (1 to 4) should be given another name. FWIW, this is how I define `hex-number-at-point'. It does not take into account the special syntax of any current mode or other context. It gets a sexp at point and matches it against hex digits. But (thing-at-point 'sexp) can have different behavior in different modes/contexts. (defun number-at-point-hex () "Return the number represented by the hex numeral at point. Return nil if none is found." (let ((strg (tap-thing-at-point 'sexp))) (and (stringp strg) (string-match-p "\\`[0-9a-fA-F]+\\'" strg) (string-to-number strg 16)))) (put 'hex-number 'bounds-of-thing-at-point 'bounds-of-number-at-point-hex) (defun bounds-of-number-at-point-hex () "Return bounds of number represented by the hex numeral at point. Return nil if none is found." (and (number-at-point-hex) (bounds-of-thing-at-point 'sexp))) > >In Lisp, at least, there is no number at point, in `foo-2'. > >That is, the Lisp parser (reader) would never pick up the > >`2' as a number here. > > The doc string of `list-at-point' clearly says that the list should > be a Lisp list. In the case of `number-at-point' the doc string > just says 'the number at point', without connection with the Lisp > parser. See above. It has always been a Lisp number - it has always used `form-at-point' and hence the Lisp function `read'. Things in thingatpt.el were Lisp from the beginning. If the doc doesn't always call out that behavior then it can be updated to do so. > >IOW, I agree with the bug report that `form-at-point' > >should - somehow - handle the case where `thing-at-point' > >returns a non-string. There is a bug to be fixed. But > >I'm not convinced that the fix we've implemented is TRT. > > Sure, I am open to alternative fixes. See above for one suggestion. But what is a _general_ number at point? Ideally, `number-at-point' should depend on the given context (e.g. mode - how numerals are recognized and represented in the given programming language or whatever. But what about a default behavior, for a mode that has no notion of numeral? You can perhaps look to what I've done for decimal and hex numbers: get a sexp at point and check that it is a string that matches a regexp that specifies a decimal or hex numeral. (`sexp' is mode-dependent, of course.) The definitions I use are pretty simple. They don't try to take into account signs or decimal points, for instance. We can do better, no doubt. We should have different kinds of `*-number-at-point' functions, for grabbing numbers that are decimal integers and natural numbers, numerals in exponential notation, hex, octal, etc. But the basic `number-at-point' should be, well basic. It should not try to recognize all of the above. It should just recognize, for example, decimal numerals that use simple notation. We could do worse than use Lisp numerals as the basic number notation, I think. And in any case, the current mode should decide what delimits a number. I do not want to see our basic `number-at-point' pick up 3 or -3 from the middle of `foo-3-bar' or -1 from `-'. Such behavior flies in the face of what thingatpt is about, IMO.