After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 455889 - Copy/paste of lower case hex letter does not work
Copy/paste of lower case hex letter does not work
Status: RESOLVED FIXED
Product: gnome-calculator
Classification: Core
Component: general
5.9.x
Other All
: Normal enhancement
: ---
Assigned To: Sami Pietilä
Rich Burridge
Depends on:
Blocks:
 
 
Reported: 2007-07-11 12:48 UTC by Ju1i3n
Modified: 2007-09-28 18:11 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
modified ce_tokeniser.l (366 bytes, patch)
2007-07-11 12:49 UTC, Ju1i3n
none Details | Review

Description Ju1i3n 2007-07-11 12:48:22 UTC
patch to ce_tokeniser.l

Other information:
Comment 1 Ju1i3n 2007-07-11 12:49:38 UTC
Created attachment 91621 [details] [review]
modified ce_tokeniser.l
Comment 2 Rich Burridge 2007-07-11 14:39:59 UTC
Not a bug. It's deliberate.
Most of the lower-case keyboard short-cuts are used for other commands:

[a] - Set accuracy 

[c] - Change sign  
[d] - Double-declining depreciation
[e] - Enter an exponential number
[f] - User-defined functions
Comment 3 Ju1i3n 2007-07-11 17:00:36 UTC
Yes for sure, most a-z lower letter are used for keyboard shortcuts. It could be unpleasant if you don't know that you have to type hexa characters in Upper case.

But i'm not talking about typing, but about pasting.

On paste lower-case letter aren't pass as a command, they are directly pasted in the field.

This patch is to made copy/paste usable from a tool like objdump, gdb,... to gcalctool for calculus on address.



Comment 4 Rich Burridge 2007-07-11 22:42:19 UTC
Ah, thanks for the clarification. I'll let Sami, (the author of the
arithmetic precedence code in gcalctool) evaluate it further.
Comment 5 Sami Pietilä 2007-07-23 15:28:29 UTC
Lower case hex symbols are not allowed in gcalctool because of ambiguous
cases they would create: "e" is actually reserved for neper's number if
it is not used in xey, in which case it is x*10^y.

I think the patch, as a such, can not be checked in. The problem seems
to be more complicated than the suggested solution.
Comment 6 Ju1i3n 2007-07-24 10:37:57 UTC
Ok, i see the problem.

There is probably no direct solution.

Maybe a mode with inverted lower and upper ?
where 1e+10 becomes 1E+10

Comment 7 Rich Burridge 2007-07-24 14:34:41 UTC
Here's the comment I sent Sami in email:

"One possible solution is to change the existing a-f gcalctool definitions
to be control-[a-f] as their shortcuts. Then, if we have a buffer being pasted in,
we automatically take a-f or A-F to be hex digits. That still leaves fixing up
recognizing e in scientific numbers. I like your idea of "e^". It might work.

We should think about it more for gcalctool in the next GNOME (2.21/22) release."

Comment 8 Sami Pietilä 2007-07-25 07:56:13 UTC
Here is a quote from a email I sent to Rich:

"I guess the only way to support lower case hex symbols is to define
non-ambiguous syntax, which has lower (and upper) case hex symbols."
Comment 9 Rich Burridge 2007-09-06 14:40:22 UTC
There is now a proposed solution to this for gcalctool for GNOME 2.21/22.

There are two currently open bugs involved here:

http://bugzilla.gnome.org/show_bug.cgi?id=455889
http://bugzilla.gnome.org/show_bug.cgi?id=469245

(and an old one - bug #118826).

Before 24th September 2003, hexadecimal input used to be "a" - "f".

This was changed to "A" - "F" because of bug #118826
http://bugzilla.gnome.org/show_bug.cgi?id=118826 

The plan now is to change them back to "a" - "f".

There are a set of other functions where the keyboard shortcut will
be reverted to their original (pre Sept 2003) upper case values:

[A] - Set accuracy  
[C] - Change sign   
[D] - Double-declining depreciation
[E] - Enter an exponential number
[F] - User-defined functions

With copy/paste operations, where the user is pasting a string into
gcalctool, the copy buffer will be iterated over. If an "A", "B", "C",
"D" or "F" character is encountered, it will be converted to its
lowercase equivalent. If an "E" is found,  and the next character is a
"-" or a "+", then it remains as an upper case "E" (it's assumed to be
a possible exponential number), otherwise its converted to a lower case "e".

Displaying of hex digits in the gcalctool display should still be
in uppercase. Displaying of the "e" in an exponential number should
still be in lower-case.

In both left-to-right precedence and arithmetic precedence modes, if
the user tries to enter a numeric digit that is incorrect for the
current numeric base, then this shouldn't be allowed. This is already
the case for left-to-right precedence.

The gcalctool documentation (and tooltips) will be updated to reflect
these changes.

I think that covers everything raised in bug #455889 and bug #469245.
If I've missed anything, or you see any problem with this proposed 
solution, please let me know.

When the gcalctool 5.20.0 release is out the way, and the code has been
branched, I'll start looking at what's needed to make these changes.
Comment 10 Rich Burridge 2007-09-10 18:19:56 UTC
Work to try to fix this bug is part of the current patch(es) to bug #469245.

Comment 11 Rich Burridge 2007-09-28 18:11:00 UTC
The fix for bug #469245 has been checked in. See:

http://bugzilla.gnome.org/show_bug.cgi?id=469245#c15

for more details.

Closing this bug as FIXED. If you find and problems or
have any further comments, please add them to bug #469245.

Thanks.