From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Visuwesh Newsgroups: gmane.emacs.bugs Subject: bug#69239: 30.0.50; number-at-point and bounds-of-thing-at-point disagree Date: Sun, 25 Feb 2024 10:12:10 +0530 Message-ID: <87sf1hi28t.fsf@gmail.com> References: <871q9c4mtv.fsf@gmail.com> <86o7c6z0f3.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29923"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 69239@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Feb 25 05:44:05 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1re6Mv-0007et-32 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 25 Feb 2024 05:44:05 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1re6MW-0001fZ-0e; Sat, 24 Feb 2024 23:43:40 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1re6MU-0001fR-Rz for bug-gnu-emacs@gnu.org; Sat, 24 Feb 2024 23:43:38 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1re6MU-0006wJ-K4 for bug-gnu-emacs@gnu.org; Sat, 24 Feb 2024 23:43:38 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1re6Ms-0005pR-L6 for bug-gnu-emacs@gnu.org; Sat, 24 Feb 2024 23:44:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Visuwesh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Feb 2024 04:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69239 X-GNU-PR-Package: emacs Original-Received: via spool by 69239-submit@debbugs.gnu.org id=B69239.170883622722341 (code B ref 69239); Sun, 25 Feb 2024 04:44:02 +0000 Original-Received: (at 69239) by debbugs.gnu.org; 25 Feb 2024 04:43:47 +0000 Original-Received: from localhost ([127.0.0.1]:37809 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1re6Mc-0005oH-PC for submit@debbugs.gnu.org; Sat, 24 Feb 2024 23:43:47 -0500 Original-Received: from mail-oo1-f66.google.com ([209.85.161.66]:52586) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1re6Ma-0005nj-HE for 69239@debbugs.gnu.org; Sat, 24 Feb 2024 23:43:45 -0500 Original-Received: by mail-oo1-f66.google.com with SMTP id 006d021491bc7-5a027fda5aeso1172580eaf.1 for <69239@debbugs.gnu.org>; Sat, 24 Feb 2024 20:43:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708836134; x=1709440934; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=6xvOfvpiMENImMIC4px67D54yIl/sXKQrP0tmWoax0E=; b=hS0lXMmzsbNifz3uWfwp2ZSMf8QXMJcmBSYEuOJNSaQnVSWaOyOrOri+4zLJcrxGRv JNhZpGjtyOuFirE3nLxx2j1pt6yt6Siotnh6/7v1Jm5c/ioFWeLAfcDKc2iimm7ER3XD TTV0PqmneD/9DvX7PIKA/MVqlizU0glQOWluV6JUan5T8cMBQm40mmnB1YNVy+ms2t6z Nf1CTZZLEWedukxjWkAHG5Tcmzymc40w6VjSKTym/Q8+vQIIsxJ3y9kEuyb2ZjgebsqJ SFnsaKaJMBPFwKX6cnER4eJ0ImuMm6/Kqab317QoXbX/nqa3YUuXyamAgc6PzcWU/cbK xAuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708836134; x=1709440934; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=6xvOfvpiMENImMIC4px67D54yIl/sXKQrP0tmWoax0E=; b=UprC0167QnCuJ/0H2FUfemb7BRdZ00n9rhmRImsrG+NM79qIeOWLU5lOl4vpljn5cZ putOnq/n42MsODFwVkJuW48d1/VI3OVvezRRCUCMER2IUHM//PmHtVb7iJczBUF2ZJjg peW/nbo2RpQ59uY70IkIyp4FBPPDV3JBnpGxBAdk8NxpznEEjP8y4yIpGxBf8NBb5KXr xkIiK/cW6cBC4oxMKG8FdK0VwIuZH788UcBzSNASGwWLn6ygBfi9MVqtzSp4AcFS6thq i7c3lkNNxXbI+ixH7AxnJx14THN5waHd+S3+NdUjAkw1XY/4dO+CzUQYRfNpD+7Cr1ma KrUw== X-Gm-Message-State: AOJu0Yx/mMkoBKEPKS0RMe0MSa5/d0QVyKlvmpxbEmb2Sj6m0qmJbBlR BSSGLoURy8TnF3sBPPiigxen9OV8iAFLCktZfZFQzCw6Z+1Z9kM4 X-Google-Smtp-Source: AGHT+IFR5ccINr+8xGdc3xhf6JOXrGPTSNkn42WSMU3oWYuXF4uO1IdjBdfCv6B5KjlnEBuIX9YE0w== X-Received: by 2002:a05:6358:16d4:b0:17b:6171:adaa with SMTP id r20-20020a05635816d400b0017b6171adaamr6210891rwl.20.1708836133667; Sat, 24 Feb 2024 20:42:13 -0800 (PST) Original-Received: from localhost ([118.185.152.162]) by smtp.gmail.com with ESMTPSA id fy16-20020a17090b021000b0029aac9c523fsm866888pjb.47.2024.02.24.20.42.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 24 Feb 2024 20:42:13 -0800 (PST) In-Reply-To: <86o7c6z0f3.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 24 Feb 2024 11:17:20 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:280585 Archived-At: [=E0=AE=9A=E0=AE=A9=E0=AE=BF =E0=AE=AA=E0=AE=BF=E0=AE=AA=E0=AF=8D=E0=AE=B0= =E0=AE=B5=E0=AE=B0=E0=AE=BF 24, 2024] Eli Zaretskii wrote: >> From: Visuwesh >> Date: Fri, 16 Feb 2024 17:56:20 +0530 >>=20 >>=20 >> The bounds returned by (bounds-of-thing-at-point 'number) does not match >> the bounds of the number returned by number-at-point. To demonstrate: >>=20 >> 1. emacs -Q >> 2. Write any number in the scratch buffer, say 14.6. >> 3. With point on the number, say M-: (number-at-point) RET and >> observe 14.6 being returned. >> 4. Now say,=20 >>=20 >> M-: (let ((x (bounds-of-thing-at-point 'number))) (buffer-substri= ng (car x) (cdr x))) RET >>=20 >> and observe the incorrect value of 14 being returned. >>=20 >> This is because the 'forward-op' property for 'number' thing is >> forward-word which fails in certain modes (not just in Elisp buffers, >> but also in LaTeX buffers). What do you think about a patch like below >> that adds an explicit bounds-of-thing-at-point property to 'number' >> thing? > > We could perhaps add something like this, but I don't think > bounds-of-thing-at-point can call THING-at-point for some THING, > because thing-at-point will cal bounds-of-thing-at-point, so this > could lead to an infinite recursion, right? Looking at the definition of thing-at-point, it checks if THING's symbol property 'thing-at-point is non-nil first before falling back to using bounds-of-thing-at-point for THING. (cond ((let ((alist thing-at-point-provider-alist) elt result) ... result)) ((get thing 'thing-at-point) <<<<<<< (funcall (get thing 'thing-at-point))) (t (let ((bounds (bounds-of-thing-at-point thing))) <<<<<<< (when bounds (buffer-substring (car bounds) (cdr bounds)))))) Since number already has the property 'thing-at-point defined, we should be fine with using number-at-point in bounds-of-thing-at-point function for number. > So the implementation will need to change not to call number-at-point. But if you want to be on the safer side, then I can write a patch that doesn't use number-at-point.