Example of displayed value on hover of `NUMERIC-EDITED` variables

[NeoKaios]

Closes #296 Note that picture string with P and E character are not yet implemented

[nberth]

I guess at the moment adding lsp = ">=1.18 & <1.19" in the cobol_lsp/package.toml should do fine. We upgrading that should be kept for a separate PR.

[NeoKaios]

P are still not supported: I think there is an issue/missing info when building the category of vars whose picture string contains Ps Because picture string V99 and P9 lead to the exact same category NUMERIC(digits = 2, scale = 2, with_sign = false) (Also PP is valid in superbol even tho it's not a valid picture string.) The handling of PIC 9P and similar should be doable, but needs to be done separately because of the scale = -1

I didn't do E because I only found 1 example in the docs. Now that I think about it, I suppose that the implementation reflects scientific notation so it can be done, tho without feedback, as cobc issue an error when an E is present libcob: error: cob_move_display_to_edited: invalid PIC character E

Atm, items with E and P simply do not have a e.g clause

[nberth]

P are still not supported: I think there is an issue/missing info when building the category of vars whose picture string contains Ps Because picture string V99 and P9 lead to the exact same category NUMERIC(digits = 2, scale = 2, with_sign = false) (Also PP is valid in superbol even tho it's not a valid picture string.) The handling of PIC 9P and similar should be doable, but needs to be done separately because of the scale = -1

In itself it's not an issue if two distinct picture strings lead to the same representation (there's no requirement like this in the language). Maybe it's actually just a missing post-scan check for rejecting P+ (the regexp) as picture strings so we don't wrongfully assign them a meaning (there are other ad hoc "post-scan" checks like this, because of the way I wrote the scanning of picture strings). Also note GnuCOBOL has issues with some picture strings due to the way it scans them (but I don't remember which ones; there may be a bug report somewhere about that), so it's not an ideal reference.

I didn't do E because I only found 1 example in the docs. Now that I think about it, I suppose that the implementation reflects scientific notation so it can be done, tho without feedback, as cobc issue an error when an E is present libcob: error: cob_move_display_to_edited: invalid PIC character E

Ah indeed it's possibly not supported yet. So we can ignore those for now.

Atm, items with E and P simply do not have a e.g clause

Ok fine with that.