GNU bug report logs - #24969
26.0.50; number-at-point

Previous Next

Package: emacs;

Reported by: Andreas Röhler <andreas.roehler <at> easy-emacs.de>

Date: Sun, 20 Nov 2016 12:40:02 UTC

Severity: minor

Tags: unreproducible

Found in version 26.0.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
To: Drew Adams <drew.adams <at> oracle.com>, Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: Stephen Berman <stephen.berman <at> gmx.net>, 24969 <at> debbugs.gnu.org
Subject: bug#24969: 26.0.50; number-at-point
Date: Mon, 21 Nov 2016 07:48:47 +0100

On 20.11.2016 22:28, Drew Adams wrote:
>>> 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.
>> In use here for edit-purposes.  For example raise all numbers
>> in a region - makes it easier sometimes to adapt stuff, which
>> doesn't deserve an own template.
> But the question is, "What constitutes a numeral?" in the given
> context.  Whatever the context, I would expect some kind of
> well-defined delimiting.  In Lisp I would expect what the Lisp
> reader would pick up as a number - nothing more.


The perspective of the lisp-programmer and the user of an editor may be 
different here.
The implementation at progress should pick any valid hex- octal- or 
decimal integer at point.

In a related case even characters are raised here, returning a "b" for 
an "a", an "y" for an "x" etc.
Thus smart-inserting a second (loop)-variable given there exist already 
a first one.


>    And that would
> exclude picking up `2' within `foo-2'.

Not, when for example filenames inside shell-scripts etc. are edited.


>
>> Have a first implementation with ar-add-numbers in
>> https://github.com/andreas-roehler/werkstatt/blob/master/misc/misc-
>> utils.el - just re-writing it.
> There is no `ar-add-numbers' or `add-numbers' in that file
> (having downloaded it just now).  Perhaps you meant
> `ar-add-to-number-cummulative'?  That is undefined, without
> `ar-bounds-of-number-atpt' (not in the file).

Errrm, ar-add-to-number should DTRT, sorry.





This bug report was last modified 3 years and 288 days ago.

Previous Next


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