[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24969: 26.0.50; number-at-point
From: |
Drew Adams |
Subject: |
bug#24969: 26.0.50; number-at-point |
Date: |
Mon, 21 Nov 2016 06:22:20 -0800 (PST) |
> > 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.
Too vague.
> The implementation at progress should pick any valid hex- octal- or
> decimal integer at point.
I disagree. Users should control whether they want a decimal,
octal, or hex number at point - or any kind of number. Those
are different things. In my code I define hex and decimal number
at point functions. When code wants to get only a decimal number
it does not want to pick up `FACE'. When code wants an octal
number it does not want `987'.
And nothing prevents a given context from defining a "number"
category. That's we had, for Lisp numbers. Other modes are
free to define a number syntax such that the (previous)
implementation of `number-at-point' - or any local,
mode/context-specific implementation, is in charge.
> In a related case even characters are raised here, returning
> a "b" for an "a", an "y" for an "x" etc.
Far too loose and useless. Thingatpt lets you define any number
of specific kinds of things. A predefined catch-all that does
lots of things that are not clear is not helpful.
> > In Lisp I would expect what the Lisp reader would pick up
> > as a number - nothing more. And that would exclude picking
> > up `2' within `foo-2'.
>
> Not, when for example filenames inside shell-scripts etc. are
> edited.
What part of Lisp reader was not clear? The (previous)
implementation uses what the current mode considers a number.
It is based on the Lisp reader, but users (or Emacs) can define
other number readings.
- bug#24969: 26.0.50; number-at-point, Andreas Röhler, 2016/11/20
- bug#24969: 26.0.50; number-at-point, Stephen Berman, 2016/11/20
- bug#24969: 26.0.50; number-at-point, Andreas Röhler, 2016/11/20
- bug#24969: 26.0.50; number-at-point, npostavs, 2016/11/20
- bug#24969: 26.0.50; number-at-point, Drew Adams, 2016/11/20
- bug#24969: 26.0.50; number-at-point, Noam Postavsky, 2016/11/20
- bug#24969: 26.0.50; number-at-point, Drew Adams, 2016/11/20
- bug#24969: 26.0.50; number-at-point, Andreas Röhler, 2016/11/20
- bug#24969: 26.0.50; number-at-point, Drew Adams, 2016/11/20
- bug#24969: 26.0.50; number-at-point, Andreas Röhler, 2016/11/21
- bug#24969: 26.0.50; number-at-point,
Drew Adams <=
- bug#24969: 26.0.50; number-at-point, Tino Calancha, 2016/11/21
- bug#24969: 26.0.50; number-at-point, Drew Adams, 2016/11/21
- bug#24969: 26.0.50; number-at-point, Andreas Röhler, 2016/11/22