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: Sun, 20 Nov 2016 08:58:07 -0800 (PST) Message-ID: References: <87fumm9uti.fsf@gmx.net> <2b644637-6ade-b00f-aa35-07c390fc92c7@easy-emacs.de> <87twb2jkzs.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 1479661158 13438 195.159.176.226 (20 Nov 2016 16:59:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 20 Nov 2016 16:59:18 +0000 (UTC) Cc: Stephen Berman , 24969@debbugs.gnu.org To: Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 20 17:59: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 1c8VSR-0001zf-CD for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Nov 2016 17:59:11 +0100 Original-Received: from localhost ([::1]:45502 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c8VSU-0006et-KF for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Nov 2016 11:59:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50729) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c8VSL-0006dS-RU for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2016 11:59:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c8VSI-0007bF-Qf for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2016 11:59:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49140) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c8VSI-0007b7-Ny for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2016 11:59:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c8VSI-00086m-CZ for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2016 11:59: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: Sun, 20 Nov 2016 16:59: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.147966109931120 (code B ref 24969); Sun, 20 Nov 2016 16:59:02 +0000 Original-Received: (at 24969) by debbugs.gnu.org; 20 Nov 2016 16:58:19 +0000 Original-Received: from localhost ([127.0.0.1]:36306 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c8VRb-00085s-Bq for submit@debbugs.gnu.org; Sun, 20 Nov 2016 11:58:19 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:22171) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c8VRZ-00085Z-Hb for 24969@debbugs.gnu.org; Sun, 20 Nov 2016 11:58:18 -0500 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 uAKGwAkZ029117 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 20 Nov 2016 16:58:11 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 uAKGwARL017788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 20 Nov 2016 16:58:10 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 uAKGw9R5009174; Sun, 20 Nov 2016 16:58:09 GMT In-Reply-To: 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: 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:125907 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. >=20 > With 25.1 I get nil, on 26.0.50 I'm getting -1. I believe this is > due to the fix in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D24605 I see. Dunno what I think about this. I'd be interested to hear more from Tino about this. It clearly is not backward compatible. Whether it is an improvement or not, I'm not sure, in this case. I guess it depends on what a user would expect of a "number-at-point" function. A priori, I don't see why s?he would expect a non-nil answer if the numeral is embedded in text that does not delimit a numeral (e.g. non whitespace text). But maybe it is OK. Would we expect the same kind of behavior for `sexp-at-point' if a sexp were not surrounded by chars that delimit a 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. I'm partial to use of thingatpt for Lisp, but I realize that it is used in other contexts too. I would probably prefer that, whatever the context, if the context has a notion of number and its syntax (numerals) then `number-at-point' would return a number ONLY when there is really a number at point, based on the meaning of numeral in that context. If we could do that well, that would be best, I think. In the case of Lisp, it is clear (to me) that returning a number for `foo-2', with point on the `2', is wrong. I think we need to think more about this. One option is to provide two different functions, one of which does what has been done in the past and one of which tries to be smarter along the lines of fixing this bug (but not necessarily along the lines of the implemented fix). 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. I'm open to being convinced otherwise, but this does not seeme right to me, so far. It seems like we should be able to do better, here.