Wish: Be more flexible when recognizing numbers.

[fehmud]

Thank you for sharing this useful library.

It would be useful if the recognition of a number were more flexible. For instance, trying to increase a11 to a12 fails with "Not a pure number".

Thanks for your attention.

[knu]

Yeah, I've been thinking about this, but just had no chance to tackle it.
Currently this library relies on the sense of "sexp" to pick a number at point, since it seemed cumbersome to support and parse various forms of numbers. But indeed, it must be a common need to increment a number suffix like you point out. I'll probably implement a fallback when there is no pure number detected at point.

[fehmud]

Oh! I didn't know that your library was flexible in regard to recognizing numbers. That is cool! Instead of implementing a fallback yourself, what about letting users provide a fallback function themselves, on a "buffer by buffer" basis?

EDIT: With "buffer by buffer", I meant "with a buffer-local variable".

[knu]

I've implemented an original number parser and formatter so operate-on-number can detect and operate on numbers in various formats and situations. Please try out the latest version.

[fehmud]

Wow! You have performed a lot of work. I have tried the new code and the fix does work, albeit not reliably. For example, in my tests, increasing a11 to a12 works, but consider this text:

(set-frame-font "-unknown-Luculent-normal-normal-normal--13----m-0-iso10646-1")

Here, increasing either 13 or 0 fails; and increasing 10646 either fails or increases -1 instead, depending on where point is. By the way, this may be a corner case, but you may provide a way to increase the absolute value of a number because -- in this case -- "1" shold be increased to "2".

Anyway, oon--parse-number-at-point hard-codes the parsing, whereas by delegating the parsing to custom parsers, users could customize the way numbers are recognized in each mode. Therefore, instead of a big cond form, oon--parse-number-at-point should cycle through a buffer-local list of parsing functions; and the first parsing function that returns a value, "wins". If you use Company Mode for completion, this is what Company Mode does with its backends. Moreover, if the parsers that you have written were things integrated with the standard library thing-at-point, that would make them reusable in other contexts. In summary, your library could be more modular and reusable.

Thanks for your attention.

[knu]

I don't like to make things ultimately extensible and customizable before the core feature gets firm and mature. At this stage, we need to collect enough use cases including corner cases as you provided.

[fehmud]

I didn't suggest to make your library ultimately extensible and customizable. I suggested to make it usable in contexts that you can't possibly foresee. Numbers can be written in so many different formats. For instance, thousands separators could be written as 1,000,000, 1.000.000, 1_000_000, etc.; hexadecimal numbers could be written as 0xFF, #FF, FF, etc. Even if you had enough time to cover all possible cases, the order of parsing could still make your library not behave as expected in every context.

Another useful feature would be the ability to parse only the number that starts at point (without searching forward, that is). This would deal with the case:

(set-frame-font "-unknown-Luculent-normal-normal-normal--13----m-0-iso10646-1")

where the current library thinks that 13 is negative.

[knu]

Still, sounds like you are demanding a high level of extensibility and customizability. To make that happen it is necessary to define a good API to allow user to implement their own parsers and formatters.

This library is still WIP, and I'm yet to start designing an API, but in the process of experimenting some algorithms I thought up and basic modularization to make them work, to cover my own needs first. I'm not even sure yet as to what a parser should receive and return, or how a parser could be coupled and interact with a formatter.

Thanks for your patience.

[fehmud]

This library is still WIP

Well, I couldn't imagine this. Your library is included in Prelude: https://github.com/bbatsov/prelude , therefore I thought that it was stable.