bug#49588: 28.0.50; (number-at-point) doesn't work with hex prefixes

bug#49588: 28.0.50; (number-at-point) doesn't work with hex prefixes

[Remington Furman]

This is related to bug#37458 (which built on bug#8634).

(number-at-point) returns 0 when the point is at the beginning of
"0x100" and returns 100 (decimal) when the point is at the end of "0x100".  I
expect it to return 256 in either location.

(number-at-point) works as expected and returns 256 when the point is at
the "#" of "#x100".  It returns nil when the point is on "x", and 100
elsewhere.

The following works as expected (though I don't suggest it's the best
possible implementation):

(defun number-at-point ()
  "Return the number at point, or nil if none is found.
Decimal numbers like \"14\" or \"-14.5\", as well as hex numbers
like \"0xBEEF09\" or \"#xBEEF09\", are recognized."
  (cond ((thing-at-point-looking-at "\\(0x\\|#x\\)\\([a-fA-F0-9]+\\)" 500)
         (string-to-number
          (buffer-substring (match-beginning 2) (match-end 2))
          16))
        ((thing-at-point-looking-at "-?[0-9]+\\.?[0-9]*" 500)
         (string-to-number
          (buffer-substring (match-beginning 0) (match-end 0))))))

It requires two calls to (thing-at-point-looking-at) for the common case
of decimal numbers, which is unfortunate.

I also tried re-ordering the capture groups around the alternation in
the regular expression to look for hexadecimal numbers first, but that
doesn't fully work.  The following version works with the point anywhere
in "0x100", but still only works when the point is at the beginning of
"#x100".

(defun number-at-point ()
  "Return the number at point, or nil if none is found.
Decimal numbers like \"14\" or \"-14.5\", as well as hex numbers
like \"0xBEEF09\" or \"#xBEEF09\", are recognized."
  (when (thing-at-point-looking-at
         "\\(0x\\|#x\\)\\([a-fA-F0-9]+\\)\\|\\(-?[0-9]+\\.?[0-9]*\\)" 500)
    (if (match-beginning 1)
        (string-to-number
         (buffer-substring (match-beginning 2) (match-end 2))
         16)
      (string-to-number
       (buffer-substring (match-beginning 3) (match-end 3))))))

I haven't sorted out exactly why the alternation group confuses
(thing-at-point-looking-at), but I think it's because it searches
forward and backwards so the decimal group will match a portion of a
hexadecimal number.

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0)
 of 2021-07-13 built on ubuntu
Repository revision: dd34bef7d3769a8574bcee2c1e91e8445129af75
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12009000
System Description: Ubuntu 20.04.2 LTS

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils thingatpt
cl-loaddefs cl-lib iso-transl tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar
mouse jit-lock font-lock syntax font-core term/tty-colors frame
minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite charscript charprop case-table epa-hook jka-cmpr-hook help
simple abbrev obarray cl-preloaded nadvice button loaddefs faces
cus-face macroexp files window text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit
x multi-tty make-network-process emacs)

Memory information:
((conses 16 51475 8072)
 (symbols 48 6629 1)
 (strings 32 18446 1983)
 (string-bytes 1 606685)
 (vectors 16 13324)
 (vector-slots 8 175896 10382)
 (floats 8 22 49)
 (intervals 56 195 0)
 (buffers 992 10))

bug#49588: 28.0.50; (number-at-point) doesn't work with hex prefixes

[Lars Ingebrigtsen]

"Remington Furman" <remington@remcycles.net> writes:

> (number-at-point) works as expected and returns 256 when the point is at
> the "#" of "#x100".  It returns nil when the point is on "x", and 100
> elsewhere.
>
> The following works as expected (though I don't suggest it's the best
> possible implementation):

Thanks; I think that implementation makes sense, so I've added it to
Emacs 28 (with some test cases).

This change was small enough to apply without assigning copyright to the
FSF, but for future patches you want to submit, it might make sense to
get the paperwork started now, so that subsequent patches can be applied
speedily. Would you be willing to sign such paperwork?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49588: 28.0.50; (number-at-point) doesn't work with hex prefixes

[Remington Furman]

Thank you, Lars.

Yes, I would be happy to sign that paperwork.  Where can I find it?

Lars Ingebrigtsen wrote:
> "Remington Furman" <remington@remcycles.net> writes:
>
>> (number-at-point) works as expected and returns 256 when the point is at
>> the "#" of "#x100".  It returns nil when the point is on "x", and 100
>> elsewhere.
>>
>> The following works as expected (though I don't suggest it's the best
>> possible implementation):
> Thanks; I think that implementation makes sense, so I've added it to
> Emacs 28 (with some test cases).
>
> This change was small enough to apply without assigning copyright to the
> FSF, but for future patches you want to submit, it might make sense to
> get the paperwork started now, so that subsequent patches can be applied
> speedily. Would you be willing to sign such paperwork?
>

bug#49588: 28.0.50; (number-at-point) doesn't work with hex prefixes

[Lars Ingebrigtsen]

Remington Furman <remington@remcycles.net> writes:

> Yes, I would be happy to sign that paperwork.  Where can I find it?

Great; here's the form to get started:



Please email the following information to assign@gnu.org, and we
will send you the assignment form for your past and future changes.

Please use your full legal name (in ASCII characters) as the subject
line of the message.
----------------------------------------------------------------------
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES

[What is the name of the program or package you're contributing to?]
Emacs

[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]

[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]

[For the copyright registration, what country are you a citizen of?]

[What year were you born?]

[Please write your email address here.]

[Please write your postal address here.]

[Which files have you changed so far, and which new files have you written
so far?]