I just noticed that if I cut/paste some numbers that start with a zero, e.g. 02700 into kcalc the display shows 1472. This does not happen if you actually type in 02700, then you get 2700. Pasted numbers higher than some starting with zero, e.g. 02800 gives nan. Lower numbers give more weird stuff, e.g. 01200 gives 640.
That's octal system, as used in C language*. Maybe it should be only applied on paste when the user is in "Numeral System" mode. *1 decimal is NNN, octal is 0NNN, and hexadecimal is 0xNNN. *2 and probably a few others inherited it
... and 0bNNN is binary, which I think C only allows in very recent versions.
OK. I see that but as you say I am in Science Mode. Obviously manuall entering 02700 gives the correct 2700 so the problem is with the interpretation of pasted numbers only. Whatever logic is applied to manual entry should also apply to pasted entries.
This particular feature has always been a bit of a sticking point because it makes complete sense if you expect it, and is nothing but confusing if you don't expect it. I like S. Umar's logic in that "pasting should have the same effect as typing", except that model doesn't fit pasting hex values such as 0x1234. Really, probably the ideal solution is to add a new set of options to manage this, I can imagine at least two: 1. "Use C conventions while pasting numbers with prefixes that indicate the base" (we can work on the wording :-P). Basically, just let the user shut this feature off, but default to on to maintain current behavior. 2. "Switch modes to match the base of pasted numbers", basically we can have it switch to hex if they paste "0x1234" automatically, which would be less confusing if expected as it would show the number they actually pasted. However, it could be VERY confusing if the user pastes 010, and expects to get 10 instead of 2... If this were to exist, it should of course default to off by default.
Changing status to CONFIRMED; both solutions appear reasonable to me. If someone wants to implement this it might be productive to get in touch with the VDG to figure out a solution that does not confuse users.
*** Bug 407009 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 447347 ***