https://bugs.kde.org/show_bug.cgi?id=398849
Gabriel Barrantes changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://bugs.kde.org/show_bug.cgi?id=398849
Christoph Feck changed:
What|Removed |Added
CC||get.so...@gmail.com
--- Comment #6 from Christ
https://bugs.kde.org/show_bug.cgi?id=398849
Julian Schraner changed:
What|Removed |Added
CC||m...@xyquadrat.ch
Ever confirmed|0
https://bugs.kde.org/show_bug.cgi?id=398849
--- Comment #4 from Evan Teran ---
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 h
https://bugs.kde.org/show_bug.cgi?id=398849
--- Comment #3 from S. Umar ---
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 shoul
https://bugs.kde.org/show_bug.cgi?id=398849
--- Comment #2 from Christoph Feck ---
... and 0bNNN is binary, which I think C only allows in very recent versions.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=398849
--- Comment #1 from Christoph Feck ---
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 ot
