GNU bug report logs - #69239
30.0.50; number-at-point and bounds-of-thing-at-point disagree

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: 69239 <at> debbugs.gnu.org
Subject: bug#69239: 30.0.50; number-at-point and bounds-of-thing-at-point disagree
Date: Sat, 24 Feb 2024 11:17:20 +0200

> From: Visuwesh <visuweshm <at> gmail.com>
> Date: Fri, 16 Feb 2024 17:56:20 +0530
> 
> 
> 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:
> 
>     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, 
> 
>        M-: (let ((x (bounds-of-thing-at-point 'number))) (buffer-substring (car x) (cdr x))) RET
> 
>        and observe the incorrect value of 14 being returned.
> 
> 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?  So the implementation
will need to change not to call number-at-point.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.