bug#69239: 30.0.50; number-at-point and bounds-of-thing-at-point disagree

[Visuwesh]

[சனி பிப்ரவரி 24, 2024] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm@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?

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.